The code was working. The product still wasn’t finished.
When I started building my own digital products, I naturally thought about the work in terms of the application itself.
There was PHP to write, a database to design, features to connect and interfaces to build. Once the core functionality worked, it seemed reasonable to think that most of the difficult work was behind me.
That turned out to be a poor way of measuring progress.
The application worked because I already understood it. I knew how to install it, which settings mattered, what each field was supposed to do and why certain workflows had been designed the way they were.
Giving the same software to someone else changes the standard.
Installation needs to make sense without me explaining it. Configuration needs documentation. Error and empty states matter. The interface has to work on different screen sizes. Demo data has to look believable. Screenshots need to explain the product rather than simply prove that a page exists.
Then there is everything required to put the product in front of someone: product pages, documentation pages, SEO, analytics, screenshots, packaging and content.
None of this necessarily adds another major feature.
That is the part I find interesting. The software can remain largely the same while the amount of work around it grows considerably. I used to think of that surrounding work as what happens after development. Now I see much of it as product development itself.
It has also made me less interested in measuring progress purely by feature count. Removing confusion or making installation understandable may add nothing to a feature list while making the product much more usable.
For other founders building software alone: at what point do you personally consider an application a product rather than simply working software?
Optional further reading:
https://cordinant.com/blog/the-real-cost-of-building-a-digital-product
I totally relate to the feeling that the software can seem ready but there's still so much left to do in terms of packaging and presenting it well. When I launched my own product, I realized that polishing the non-code aspects was just as essential as the coding itself.
For SEO and content strategies, I've found that using a solid content growth platform can really streamline the process. Personally, I’ve used Scaleblogger for managing and optimizing my content strategy – it helps me automate and improve the quality of the SEO content, which saves a ton of time. You might also look into tools like Ahrefs for keyword research and metrics, and combining them with project management tools like Notion or Trello can help keep everything organized as the workload fluctuates.
As for analytics, setting up Google Analytics from the beginning was crucial for me to track user interaction effectively. Using tools like Hotjar to visualize user behavior can also be really insightful. In the end, it’s about finding the right balance between the product features and how you articulate its value to the users.
Keep pushing through; it’s all part of the indie founder journey!
Thanks for the suggestions. I already use Google Analytics and Search Console, but I'm still learning what kind of content and promotion actually brings the right people to my products.
I agree that the non-code part can take just as much work as development. Building the product feels much more predictable to me. Explaining its value, creating content, working on SEO and finding the right audience is a completely different challenge.
I'm still at the beginning of that part, so I'm trying different approaches and seeing what works.
That makes sense. Development often feels more predictable, while finding the right message, content, and audience takes experimentation. Focusing on meaningful actions such as sign-ups or enquiries not traffic alone should make it easier to see what is working. Wishing you the best as you continue testing different approaches!
Thank you))
The line that got me was "error and empty states matter". That is the exact border between working software and a product someone else can hold.
The move I use: pick one screen and write out its three production states before touching features. What it shows while loading, what it shows with nothing in it yet, and what it says when the call fails and the person still has to decide what to do next. A screen without those three is a demo wearing a product costume.
Installation is the same idea one layer up. It is the empty state of the whole thing.
Wrote up the checklist I run on this: https://durablefoundations.gumroad.com/l/pyramid-reality-check
Which screen in yours has the weakest failure state right now?
Kael Voss / DurableFoundations
I like the idea of thinking about installation as the empty state of the whole product. I hadn't looked at it that way before.
For me, failure states are still something I tend to discover while testing rather than planning from the beginning. Usually the main flow gets most of my attention first, and then I find all the less obvious cases later.
Your three-state approach sounds like a simple way to catch more of those problems earlier.