|
| 1 | +--- |
| 2 | +title: "Build Notes: Where is my time spent when building two micro-apps?" |
| 3 | +date: "2024-01-22T18:49:20.128Z" |
| 4 | +--- |
| 5 | + |
| 6 | +In the past week I built and deployed two micro-apps. |
| 7 | + |
| 8 | +I was curious what exactly would take the most time so took fairly detailed notes as I went so I could write this post. |
| 9 | + |
| 10 | +First a bit about the apps and then I'll breakdown the time spent and draw a few implications. |
| 11 | + |
| 12 | +### Chocolate Batches ([code](https://github.com/KyleAMathews/chocolate-batch-tracker)) |
| 13 | + |
| 14 | +My wife and I have gotten into making bean-to-bar chocolate over the last year. If you like cooking and you like chocolate, it's a very fun (and delicious) hobby. I'll be writing a separate post about this soon actually. |
| 15 | + |
| 16 | +We didn't have a consistent way to store information about what we were making, recipes and origins |
| 17 | +we were trying, and tasting notes. We had a spreadsheet but it's fiddly to use and extend. |
| 18 | + |
| 19 | +So I thought that of course, a new little micro-app would be great for this. |
| 20 | + |
| 21 | + |
| 22 | + |
| 23 | +### Primal Pulse ([code](https://github.com/KyleAMathews/primal-pulse)) |
| 24 | + |
| 25 | +My goal this year is to get to 12 hours of movement / week. Inspired by [Alan Couzens](https://twitter.com/Alan_Couzens) research on how fundamental large volumes of low intensity movement is to good health and as the foundation to all fitness. The name "Primal Pulse" is after the idea that our bodies evolved to work like they did in pre-modern societies i.e. moving all the time. And that much of our health/fitness issues trace to that we're resting constantly. |
| 26 | + |
| 27 | +So a good option for a micro-app to track this. I record all my activities from my Garmin watch (walks, runs, bike rides, resistance workouts, etc.). I wrote a script that pulls the data from Garmin and writes to a Postgres database which syncs to my client with [ElectricSQL](https://electric-sql.com/) where I create the chart of weekly/monthly movement (with a [fancy SQL query](https://github.com/KyleAMathews/primal-pulse/blob/7ba6a240e5a3c981df0583a36fd7226f494df0f0/src/routes/index.tsx#L155-L186) that ChatGPT made for me). |
| 28 | + |
| 29 | +I'm currently around 5-6 hours / week of movement so a ways to go still. |
| 30 | + |
| 31 | + |
| 32 | + |
| 33 | +## Hours |
| 34 | + |
| 35 | +It took ~19 hours to build the Chocolate batches app and ~9 hours to build the Primal Pulse app, spread over the last week or so. |
| 36 | + |
| 37 | +For the Chocolate app I spent: |
| 38 | +- 2 hours on design (typography, colors, general layout) |
| 39 | +- 9 hours on interactivity (forms, etc) |
| 40 | +- 4 hours setting up dev environment |
| 41 | +- 4 hours setting up prod environment |
| 42 | + |
| 43 | +For the Primal Pulse app I spent: |
| 44 | +- 2 hours on dev/prod setup |
| 45 | +- 1 hour on fine-tuning the chart (I had a similar one on a previous app that I ported over). |
| 46 | +- 6 hours researching/learning new tools — most of which was finding the best way for longer-running serverless functions. I evaluated half a dozen tools before settling on [SST](sst.dev)'s setup for AWS Lambda functions. |
| 47 | + |
| 48 | +## Analysis |
| 49 | + |
| 50 | +The most general conclusion I can make is that doing anything novel takes much much longer than anything I'm repeating. |
| 51 | + |
| 52 | +E.g. setting up my basic development environment for my ElectricSQL apps. I first hand did this with Vite and React last fall over a day or two, etc. then spent a day converting that into a starter which I've since refined over 5 apps now. That's days of work to learn those things which is now compressed into running one command and about 3 minutes of work to get going on a new project. |
| 53 | + |
| 54 | +It's the same with my production environment. It took two days to figure out everything when deploying my first app. Now it's a checklist I follow that takes me ~40 minutes. And I'm planning on adding some minor automation that'll cut that in half again. |
| 55 | + |
| 56 | +You can see that across these two apps. Just with the experience from the chocolate app, I went from ~8 hours to ~2 hours setting up dev/prod. |
| 57 | + |
| 58 | +You can just ferociously compress how long it takes you to do simple things — as long as you repeat them a few times. |
| 59 | + |
| 60 | +I read a great book recently: [How Big Things Get Done](https://www.amazon.com/gp/product/B0B3HS4C98/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1). A very readable and insightful book into what factors make large and small projects go well and fast or slowly fail. Two factors he discusses are the role of experience and modularity. Which in my mind are often the same thing. If you can make your tools and workflows "modular" i.e. reusable across multiple projects, then you'll go up the experience curve on these much faster than if they're slightly different on every project. |
| 61 | + |
| 62 | +In general, the most optimal tools and workflows aren't those that are optimal in some sort of global sense, i.e. do the most possible things for you the quickest but those that are small and simple and reusable in many contexts. You can get rediculously good at these small things fairly quickly and find lots of ways to use them where the more complicated the tool, the harder it is to actually master and the fewer opportunities you'll find to use them. |
| 63 | + |
| 64 | +E.g. turning my dev environment into a reusable starter dropped the time to start a new project to minutes from hours. Standardizing my production environment around simple customizable tools and workflows is also dropping the time to deploy a new project from days to minutes. |
| 65 | + |
| 66 | +The book talks about how nuculear plants are incredibly complex to build and how each plant tends to differ quite a bit from every other plant. And compares them to solar panals which have one tiny little solar cell which is repeated millions of times. Solar projects are very predictable as to time and costs and how the cost / GW for solar has dropped precipitiously for decades. Whereas nuculear energy seems to just get more and more costly over time. |
| 67 | + |
| 68 | +[Learning Curve](https://en.wikipedia.org/wiki/Learning_curve) is the technical term for these ideas for those looking for the Wikipedia link. |
| 69 | + |
| 70 | +So this is my grand strategy (as it were) right now — I'm looking for what to do next and the only way I know to do that is to prototype as many interesting things as possible and then eventually double-down on the most interesting. So I'm picking and practicing tools that'll allow me to build whatever interesting idea I can think of very quickly. |
| 71 | + |
| 72 | +React is my old standby and ElectricSQL is a new tool that eliminates a lot of setup and developmentglobally, the learning curve for time and gives you free real-time sync. I'm also finding that just using raw VMs & Lambdas are proving much faster than working with PaaSs as I have a lot more flexibility to do weird stuff and don't run into paywalls whenever I try to do something novel. |
| 73 | + |
| 74 | +A well-practiced, modular set of low-level tools allows for fluid exploration of higher-level concepts. |
0 commit comments