All you need is attention.
The following are December reflections as I build a thing. Dev log °2.
This blogpost has almost nothing to do with AI, instead, the following are December reflections as I build a thing in my Monthly Dev Log series.
The back and forth
Last month was all about getting a functional MVP. This required me to switch back-and-froth between the backend and the frontend to make sure everything was working. This month required a change of strategy.
There are two ways of thinking about progress. If you’re an artist trying to improve your craft, you might choose to work on the skill of painting and the skill of ceramics in a given month. Or you can fully commit to just improving ceramics. Both strategies are going to result in progress but there’s a different cost associated with each strategy.
Last month I got the MVP running, this month I decided to change strategy on making progress. The back-and-forth between implementing a backend endpoint and then switching gears to the frontend UI task just didn’t feel right. The context switching wasn’t resulting in the type of progress I wanted.
I completed all my forecasted goals and I think choosing to just work on one craft (backend) this month paid off.
It’s a Sisyphean task
The act of building something is the act of getting to know oneself. The more progress you make, the more blind spots you reveal. It’s easy to get overwhelmed by the seemingly endless todo tasks. Here’s one strategy I started at the start of this month that will help.
Make a document and write down “Version 1” at the top. Add a table bellow with the following columns: a short description of the feature, a “page” column that links to more details about that feature, and a “status” column that tracks the progress or completion. I use Obsidian, here’s an example if I was building a blogging platform:
Each one of those high-level features get their own document. You don’t need to conform to any template for these documents, you just jot down what it would take for that feature to be complete. If we click on `feature- draft posts` we might see this document:
Now, not only do you know when your product Version 1 will be ready for release, but you can break down the individual features into items that will be easy to conquer. Feature creep can also be prevented because you have a roadmap for this particular release.
Maybe now, one must imagine Sisyphus happy.
The push and pull of simplicity
I’ve been dabbling with Cursor. A code editor that has “AI code generation” built into it. It’s really impressive when it comes to boilerplate code generation. I won’t lie it is impressive but I think the hardest parts of product development still require the creator to do some deep thinking and problem solving.
Here are some shortcomings of AI code generation tools:
If you’re unfamiliar with your own code or tools, then AI will trick you. You need familiarity with your tools to build the intuition to pick up on possibly incorrect AI output.
Personal skill atrophy: probably the biggest risk of these tools. You’ll forget the skill of programming and become a “prompt engineer”. Maybe this is the future? I’m not sure. I need to reflect a bit more on this.
Complexity will slip in and you won’t even realize it. I asked Cursor to generate some boilerplate Stripe Billing checkout code and it created code with 3 different pricing tiers. Billing is complex and if I choose to blindly accept 3 different pricing tiers because my codegen tool outputted it, then I take on serious maintenance and technical debt risk.
Often the most elegant solutions are ones you need to think about. Solutions that can’t be generated regardless of large context windows.
Pricing a product is an art not a science
This is the first thing I’ll ship that’ll have at least one priced tier. This month was the first time I created a Stripe account and started to read up pricing strategies for digital products. It turns out that pricing isn’t an exact science.
One of the first things I did was ask Claude and GPT to assist with a pricing strategy. They’re kind of bad at this task. In part because they choose complexity (see previous section) or maybe they’re just bad at math.
I learnt that nothing beats a simple Excel file. Track the parts that’ll cost and then add a margin on top of it. Stripe has a lot of bells and whistles (do you want users to have free trials? coupons? monthly vs. annual discounts?). My recommendation is to start things simple. The more layers of billing code you add, the more time you’ll spend moonlighting as a “billing engineer”.
I did gain one important insight in my readings: price things higher than you’re comfortable with. Reducing the price is easier than increasing it.
Boredom is a feature, not a bug
December is a sleepy month. The perfect month to watch Japanese film Perfect Days that highlights a character in Tokyo finding the beauty in a simple life. I think we can all learn from this film.
In order to make progress all you need is attention. But at the same time, some of the best insights will not come when you’re sitting in front of your code-editor. Going on walks. Writing (which is perhaps the only thing I find harder than coding). And just having other hobbies is a crucial part of making progress.
Happy New Year. Talk to you in a month my friend.
Very nice read. Loved the emphasis on keeping things simple 👍