Some software products seem to appear almost overnight. One week there is nothing, and the next there is a polished landing page, screenshots, documentation, a blog, and an active social media presence. Looking at the finished result, it is easy to imagine a small company working behind the scenes. Sometimes that is true. Increasingly, though, it may simply be one person.
The idea of the solo founder is hardly new, but the way independent software is built today has changed considerably. Modern development tools, cloud services, open-source frameworks and, more recently, artificial intelligence have lowered many of the barriers that once made building a product alone feel unrealistic. One person can now accomplish work that might have required a small team only a decade ago.
That does not necessarily make the journey easier. It simply changes the nature of the challenges.
When people hear the phrase solo founder, they often picture someone writing code in a café or launching products from a laptop while travelling the world. Reality tends to be much less cinematic. Most days involve switching constantly between completely different kinds of work, making dozens of small decisions, and accepting that there will never be enough time to do everything you would like.
Building software alone has taught me that creating the product itself is only one part of the job. In many ways, it is simply the centre of a much larger system.
One Product Is Actually Many Different Jobs
When I first started working on my own products, I naturally focused on the software. That seemed to be the difficult part. If the application worked well and solved a real problem, surely the rest would be manageable.
I gradually realised that writing code occupies only a fraction of the overall process. Every completed feature immediately creates new work somewhere else.
A new dashboard needs documentation. Documentation needs screenshots. Screenshots require polished interfaces. Product pages need explanations. Explanations become blog articles. Articles require illustrations, SEO, metadata and social posts. Those social posts often lead to improvements on the website itself, which then create another list of development tasks.
The work expands in every direction.
While building Cordinant, I found myself moving between completely different disciplines, sometimes within the same hour. I might begin the morning designing a database schema, spend lunchtime rewriting documentation, create a hero illustration during the afternoon, and finish the evening adjusting meta descriptions or debugging CSS that only breaks in one browser.
None of those jobs feel optional. Each contributes to whether someone eventually discovers, understands and trusts the product.
Writing software is only one responsibility. Building a product means building everything around the software as well.
Why More Developers Are Choosing to Build Alone
There are practical reasons why independent software creation has become more common. Development frameworks are more mature than they used to be. Hosting has become inexpensive. Payment platforms handle much of the business infrastructure. Open-source projects solve problems that once required months of custom engineering.
Perhaps more importantly, expectations have changed. A successful product no longer needs to compete immediately with companies employing hundreds of people. Many users actively seek smaller, more focused tools that solve one problem well instead of trying to become an all-in-one platform.
That shift has opened opportunities for independent creators. Rather than chasing venture capital or building organisations from day one, many founders prefer to remain small for as long as possible. Some never intend to grow beyond a single person.
Of course, staying small also introduces constraints. A solo founder cannot realistically pursue every opportunity, respond instantly to every request or support dozens of complex products simultaneously. Independence creates freedom, but it also demands careful choices about where limited time should be invested.
Being a solo founder does not necessarily mean refusing to collaborate with others. It simply means remaining responsible for the direction and day-to-day creation of the product without a permanent team.
Choosing a Different Kind of Business
One of the decisions that shaped my own projects happened before I had even released the first one.
From the beginning, I knew I would be building software alongside a full-time job. That immediately limited what kind of business I could realistically support. Creating a SaaS platform sounds appealing, but it also creates ongoing responsibilities: hosting, uptime, customer accounts, security monitoring, support requests, regular feature releases and countless operational tasks that continue long after launch.
I realised quite early that I could probably build that kind of software, but I could not confidently promise to operate it indefinitely on my own.
That led me towards self-hosted products instead.
Instead of selling access to a service, I build complete PHP applications that customers can install and own themselves. They receive the source code, deploy it on their own servers, customise it if they wish and decide how they want to maintain it in the future.
This model naturally comes with different trade-offs. It does not remove responsibility, but it changes where that responsibility lives. Much of the ongoing infrastructure belongs to the customer rather than the creator, making the business model more compatible with working independently.
I do not think this approach is universally better. It simply fits the kind of business I felt capable of running on my own.
The Invisible Work Behind Every Visible Feature
When people browse a product website, they mostly see finished work. They see polished interfaces, concise feature lists and carefully written descriptions. What remains invisible is the long sequence of small decisions that gradually produced those pages.
For every visible feature, there are often dozens of supporting tasks that nobody notices.
Before a single screenshot appears on a product page, someone has to design realistic sample data, improve the visual layout, create consistent icons, decide which screens best represent the application, capture images at the correct resolution, optimise them for the web and integrate them into the website.
The same pattern repeats almost everywhere.
Documentation requires structure before it requires writing. SEO requires research before optimisation. Product pages require understanding before persuasion. Even choosing the name of a button sometimes involves surprising amounts of thought.
None of these jobs are especially dramatic. Together, however, they occupy a significant portion of independent product development.
That is one of the aspects of solo building I find most interesting. The software may be the reason someone arrives, but everything surrounding it quietly shapes the experience they have before deciding whether the product deserves their attention.
Artificial Intelligence Changed the Scale, Not the Nature, of Solo Building
It is difficult to discuss independent software development in 2026 without mentioning artificial intelligence. Hardly a week passes without another announcement claiming that AI will replace developers, designers, marketers or entire companies. Depending on where you look, the future appears either incredibly exciting or surprisingly bleak.
My own experience has been much less dramatic.
AI has become part of my everyday workflow, but not because it writes perfect code or magically builds complete products. Instead, it has become another tool—one that often helps me move faster, think more broadly and avoid getting stuck on routine work.
Some days I use it to explore technical approaches before choosing one myself. Other days it helps reorganise documentation, challenge an article outline or suggest improvements I had not considered. Occasionally it produces an excellent solution almost immediately. Just as often, it sends me down a path that ultimately proves unsuitable.
The most valuable contribution is rarely the first answer. It is the conversation that follows.
Working alone means there are very few opportunities to exchange ideas throughout the day. AI cannot replace another experienced developer or product designer, but it can act as a useful thinking partner. It asks different questions, offers alternative perspectives and occasionally points towards possibilities I would probably have overlooked.
Using AI has not reduced the need to understand software development. If anything, it has made good judgement even more important because every suggestion still needs to be evaluated, tested and sometimes rejected.
The final decisions remain my responsibility. The finished product still reflects the choices I make, not the suggestions I receive.
Progress Rarely Looks Like Progress
One of the more surprising aspects of building products alone is how often an entire week appears to produce almost nothing visible.
A visitor arriving on the website may struggle to spot any obvious differences, while behind the scenes dozens of problems have quietly disappeared. Database structures become cleaner. Installation becomes simpler. Documentation becomes easier to follow. Security improves. User flows become more consistent.
None of these changes create exciting screenshots, but they often make the product substantially better.
While building Cordinant, I have experienced this repeatedly. There have been evenings where I felt I had made very little progress, only to realise later that I had solved several small problems that would otherwise have complicated every future feature.
That has gradually changed how I think about productivity.
Finishing visible features certainly feels satisfying, but many of the improvements that matter most are structural rather than visual. They make future work easier instead of attracting immediate attention.
Some of the most productive days end without a single new screenshot.
The Constant Exercise of Choosing What Not to Build
Ideas rarely arrive one at a time.
If anything, building one product tends to generate several more. A feature suggests another feature. A blog post inspires a new tool. Solving one problem reveals three related opportunities that suddenly seem equally interesting.
The difficult part is not generating ideas.
The difficult part is deciding which ideas deserve attention now and which should remain unfinished notes for another day.
Working alone makes prioritisation unavoidable. Every hour invested in one feature is an hour unavailable for documentation, testing, marketing or writing. Because there is nobody else to continue those tasks, every decision carries an opportunity cost.
I have accumulated far more ideas than I will realistically build over the next few years. Surprisingly, that has become reassuring rather than frustrating.
Not every idea needs to become a product. Some simply improve another project. Others become blog articles. A few remain interesting thought experiments without ever turning into software.
Learning to leave good ideas untouched can be just as valuable as learning how to implement them.
Building Systems Instead of Individual Features
Another lesson that gradually emerged while working on Cordinant had very little to do with programming itself.
Initially, I approached each new task as something unique. Every product page, every article, every documentation section and every visual was created independently. That worked while there were only a handful of pages.
Eventually, repetition became impossible to ignore.
Every new product required almost identical supporting material. Feature descriptions followed similar structures. Documentation repeated familiar sections. Blog articles benefited from consistent formatting. SEO metadata followed recognisable patterns.
Instead of repeatedly solving the same problems, I began creating reusable systems.
The custom CMS behind Cordinant grew partly from that observation. Product templates reduced repetitive work. Structured content made publishing easier. Reusable page components kept the website more consistent. Even article creation gradually became a more organised process without becoming mechanical.
The goal was never automation for its own sake.
The goal was creating more time for genuinely creative work.
Reusable systems should reduce repetitive work, not eliminate thoughtful decision-making. Templates provide structure, but every product and every article still needs its own voice, context and purpose.
There Is Nobody to Tell You That You Are Finished
Large companies naturally create external deadlines. Releases are scheduled. Meetings happen. Other people depend on your work. Those structures encourage decisions, even when they are imperfect.
Working independently feels very different.
There is rarely a manager saying a feature is good enough. No product owner closes the ticket. No designer signs off the interface. Every decision eventually returns to the same person.
That freedom can become surprisingly dangerous.
Perfectionism becomes much easier to justify because nobody is forcing the product out of the door. Small improvements continue indefinitely. A sentence could be rewritten one more time. Another icon might look slightly better. A layout could probably become cleaner.
Sometimes those refinements genuinely improve the product.
Sometimes they simply postpone finishing.
I still find this one of the hardest balances to strike. Shipping something imperfect always feels slightly uncomfortable, yet waiting until everything feels perfect often means waiting forever.
The more products I work on, the more I suspect that completion is rarely a moment. It is simply the point where continuing to improve something becomes less valuable than beginning the next piece of work.
Success Looks Different When You Build Alone
Much of the software industry celebrates scale. Larger teams, larger funding rounds, larger customer numbers and increasingly ambitious growth targets often dominate conversations about successful businesses. It is easy to absorb those expectations without noticing.
Working independently gradually changed the way I measure progress.
Launching a product after months of development feels significant, even if only a handful of people discover it during the first weeks. Publishing a detailed article that genuinely answers someone's question can feel equally rewarding. Finishing documentation, redesigning a confusing interface or simplifying an installation process may never appear on social media, yet those improvements often have a lasting impact on the product itself.
None of these milestones make headlines.
They simply make tomorrow's work a little easier than today's.
That perspective has become increasingly important because independent product development rarely follows the dramatic stories we often hear about startups. Progress is usually gradual. Momentum comes from hundreds of small improvements rather than one breakthrough moment.
Working Alone Does Not Mean Working in Isolation
The phrase solo founder can be slightly misleading. It suggests complete independence, as though one person creates everything without outside influence.
In practice, independent creators rely on an enormous ecosystem built by other people.
Programming languages evolve because thousands of developers contribute to them. Frameworks simplify difficult problems that have already been solved by experienced communities. Open-source libraries eliminate months of repetitive work. Hosting providers, payment platforms, design resources and documentation tools all become part of the finished product, even if they remain invisible to customers.
The same applies to learning.
Many of the solutions I eventually arrive at begin with reading articles, watching conference talks, studying open-source projects or following discussions between developers with far more experience than I have. Independent creation does not happen in isolation. It happens within an environment where knowledge is shared remarkably freely.
That is one reason I wanted Cordinant to include a blog alongside the products themselves.
The articles are not intended to teach definitive answers or establish authority. They are simply another way of participating in the wider conversations that have helped me throughout my own projects.
Every independent product quietly depends on thousands of people whose names never appear on the landing page.
There Are Still Good Reasons to Build a Team
None of this should be interpreted as an argument against building companies or working with other people.
Many products genuinely require dedicated specialists. Large SaaS platforms, enterprise software, consumer applications with millions of users or products requiring around-the-clock customer support are often difficult to imagine without experienced teams behind them.
Even smaller software businesses benefit enormously from collaboration. Designers notice problems developers overlook. Technical writers improve documentation. Marketers understand audiences differently from engineers. Product managers often ask uncomfortable but necessary questions before features are built.
One person rarely possesses deep expertise across every discipline.
Working independently therefore involves accepting that some areas will always receive more attention than others. Rather than trying to outperform specialised teams at everything, solo founders often succeed by choosing projects whose complexity matches the resources available.
The question is not whether solo founders or teams are better. They solve different kinds of problems under different constraints. The most suitable approach usually depends on the product, the people involved and the business they want to build.
If I Started Again Tomorrow
Occasionally I wonder how I would approach everything if I were starting from an empty directory again.
I doubt I would spend less time planning, but I would almost certainly spend more time thinking about the systems surrounding the product instead of concentrating only on the software itself.
Documentation would no longer feel like something to finish after development. It would become part of development from the beginning. The same applies to product pages, screenshots, naming conventions and reusable design components.
I would also become comfortable saying no much earlier.
Early in a project, every interesting idea feels important. Eventually it becomes clear that unfinished ideas are not the real problem. Limited attention is.
Perhaps the biggest difference would be psychological rather than technical.
I would worry less about whether progress appeared impressive from the outside and pay more attention to whether each month left the product in a healthier state than the month before. Independent development is rarely about dramatic leaps forward. It is usually about quietly removing obstacles before they become larger ones.
Looking Further Than the Next Release
One reason I continue enjoying independent software development is that it rarely feels finished.
Every completed product changes the questions I ask during the next one. Every article uncovers another topic worth exploring. Every improvement to Cordinant makes me notice another area that could become simpler, clearer or more useful.
That constant evolution can sometimes feel frustrating because the list of ideas grows faster than the list of completed tasks.
At the same time, it keeps the work interesting.
Building products has gradually become less about reaching a final destination and more about creating an environment where future work becomes easier. Better tools reduce repetitive effort. Better documentation reduces confusion. Better systems allow new ideas to be explored more quickly.
In many ways, every project quietly prepares the ground for the next one.
It is easy to compare your unfinished work with somebody else's polished launch. Most products become visible only after months or years of invisible iteration. Judging progress solely by what appears publicly can create a misleading picture of how software is actually built.
Still Building
When I began creating my first product, I imagined that success would eventually feel like reaching a point where everything became easier. There would be established processes, polished products and enough experience to avoid uncertainty.
That has not happened.
The questions have simply changed.
Instead of wondering whether I can build a product, I spend more time wondering whether I am building the right one. Instead of searching for the perfect technical solution, I think more about long-term sustainability. Instead of trying to eliminate uncertainty, I have gradually accepted that uncertainty is part of independent creation.
Building products as a solo founder is not an attempt to do every job better than a team could. It is an exercise in making thoughtful trade-offs, working within realistic limits and gradually constructing something that reflects both your abilities and your constraints.
Cordinant is still evolving. The products are still evolving. My way of working continues to evolve as well. Looking back, that ongoing process feels far more representative of independent software development than the idea of eventually arriving at a finished destination.
Perhaps that is what I appreciate most about building alone. Every new project begins with uncertainty, every finished project raises new questions, and every step quietly expands what feels possible for the next one.
