Prototyping products quickly
Disclaimer: This post is aimed at people with experience in programming or software engineering and will not discuss no-code or low-code solutions.
I've been trying to build out a few products now, and have not necessarily succeeded at this by most measures, but I figured I would keep writing about it to try and build out a process that helps me reflect on what I do and iterate further. In addition to this, hopefully I can build a platform of knowledge that others may find useful.
Today, I wanted to talk about prototyping products and what I found a useful 'formula' for building stuff fast.
Let's start with the obvious: think about your problem. My latest endeavour is PennyPal.app. This problem is super straightforward and the prototype for this took approximately 3 days. Essentially, I wanted to build something that can replace my own personal finance spreadsheet that I use for low-touch budgeting. More a 'knowledge-store' of "this is what my finances look like right now".
From learning how to program, especially in the world of web, there's a lot of focus on scaling things or using the shiniest tech. For this project I took a simpler approach - half-ass everything. Maybe it lands you with a mediocre product but at least you get a baseline P.O.C that you can show people and gain feedback. This is the most important step to get over and having a feedback loop is crucial.
How did I get this done fast? The first core principle I can think of is to 'stick to what you know'. There's a great talk on this which talks about 'innovation tokens' (Choose Boring Technology). The (butchered) summary of this is basically: keep it simple and then you can focus on building out the solution to your problem rather than learning some new tech that your customer probably doesn't care about or interact with anyway. In the case of PennyPal I opted for React (later shimming this out with Preact for the technical curiosities - there's one innovation token gone!) with a super-simple Go backend that I use buf.build's connectRPC for proxying between the web and the backend itself... that's another innovation token gone! I am perhaps cheating in saying that I am reasonably familiar with these technologies so that helped me build faster.
The second principle is to put on your Amazonian hat and obsess about the customer. In this case, I am the customer, so this is a bit of a tricky one to balance! Being ruthless helps, and I ended up stopping where possible to reflect on my backlog of tasks and think 'Is this the best thing I can be doing right now with my time?', for instance, I wanted a feature for splitting a transaction by a ratio e.g. if you share an expense with your partner. This is something I'd love to do but it's not relevant and would not contribute to a solid foundation for a product. By not doing this, I remove a TON of work, potential bugs added, and a feature that's complex and I don't necessarily have any way of validating or proving the value of this feature. And trust me, the way I would like this feature to work would add some significant complexity.
The third piece of advice I could offer - do it half-assed! Being ruthless not only applies to what you do but HOW you do it. I had a thought here, there is a bunch of software that is fairly straightforward that people build, such as a personal finance app (likely a programmer trope by this point) where we* over-engineer things or maybe we* plummet into a learned helplessness of doing the same thing over and over. This is going to contradict my first point, but sticking to what you know is a great thing to do for the foundations, e.g. a language choice or a hosting platform, but you need to ask yourself is hosting this on Kubernetes really necessary? Do I really need a REST api? For the most part, the answer is probably a resounding NO!
*we... I.
Really grokking those foundational pillars of how you build product is something that can help you iterate faster. Question the fundamentals. A few learnings in practice I took from this project are things like:
- this probably doesn't even need to be a web-app. if you really want to solve a problem maybe a spreadsheet is fine. there might be more value if anything to build out a template of a spreadsheet and share it with people. that's a valid solution in itself!
- ok we'll build a web-app anyway. it means i can have a progressive-web-app which can vaguely operate on mobile devices. the personal problem I experience is that the UX of a google spreadsheet on a mobile device (iphone) is awful. can i fix that?
- but with a web-app you don't NEED state to be in the cloud. just because it's on the internet and accessible that way does not mean that you need to have a backend integration going on. from this, i ended up relying on IndexedDB which is essentially a browser-side database that you can query from the frontend so even if you close the browser and re-open it a week later your data still persists.
- but then, i still want my data to be accessible from multiple devices. well, rather than split everything up into endpoints and ping data over to a backend or whatever you end up doing... just send the entire database state over in one request to the 'cloud'. it solves the problem immediately, there are certainly tradeoffs and this software is not inherently good, ...but it works and it solves my problem.
Maybe at the end of the day there is a balance to figure out here.