Categories
The Narrative

Going It Alone: Building a Software Product as a Solopreneur

Yes, I am a solopreneur, but would I recommend becoming a one? That does depend on you, because it’s a demanding lifestyle…

I’m Wayne, founder of Octane based in England, started in 1999, and I build workflows for small and mid-sized businesses.

I’m also the man behind Under Cloud, the place to transform notes and research into resilient, visual, and decision-ready knowledge.

Here’s what I’ve learned from going it alone…

Going solo(preneur)

Yes, I am a solopreneur, but would I recommend becoming a one? That does depend on you, because it’s a demanding lifestyle that required the following of me:

  • A willingness to work in isolation for long periods of time;
  • An aptitude and an appetite to learn different disciplines;
  • A resourcefulness and resilience to thrive while working alone;
  • An ability to make the most of meager resources;
  • That I learn to live with and sometimes capitalise on the uncertainties;
  • That I be tenacious and resolute under pressure;
  • That I cultivate a reliable instinct;
  • That I endure criticism and (self) doubt.

I’ve ignored almost all of the advice I’ve been given, not because it was wrong but because it was inapplicable to my circumstances. When thinking about advice, I have two options:

  1. adapt my circumstances to meet with the advice;
  2. adapt the advice to meet with my circumstances.

Most of the time, these options have been too expensive.

My opinion has become a consensus of one, a single data point from which I’ve built bit by bit through experience. Knowing when that consensus is the best path to take, and when to expand on it is a constant challenge.

I have a few reliable people in place who I turn to when building on that consensus, people who’re not always like-minded, and perhaps not people I’d think of as friends, but I at least trust their professional opinions because they’re grounded in experience relevant to the task at hand.

I don’t often trust the opinion of friends because there’s a risk of bias. Give me a harsh but qualified “No!” instead of an amenable “Yes!” any time.

My decisions are final (a statement that must seem obvious, at first glance), and there are some major advantages at work, here. First, because I don’t have a co-founder, the consensus of one comes into its own, saving valuable time. Second, the distance between decision and action is imperceptible, because the person making the decision is the same person implementing it (me), eliminating some of the major problems I’ve seen with communication across a team and between teams. The most obvious caveat here is that my failure rate (and by extension, the cost of those failures) has to be kept low. Yes, fail fast, but be a failure cheapskate!

Some decisions I’ve made aren’t like some poor line of code, where I hit that safe keyboard combination to undo them. I’ve sometimes had to zig because of that consensus while everyone has zagged, and then live with the consequences of that decision.

There is one attribute I’ve not mentioned, but is explained by one of the articles in this knowledge graph:

This [non-stop switching between fundamentally different tasks] can lead to a loss of focus, energy and, over time, to decision fatigue, where even the small choices start feeling exhausting.

I’ve learned to switch focus on demand, and there is a simple technique to improve how we do this:

Group similar tasks together – for example, handle all the financial tasks on Monday morning instead of scattering them throughout the week.

I built Under Cloud to fix challenges such as these.

I asked almost 300 specialist researchers about their knowledge management challenges:

  • Workflows are a mad composite of different products and services.
  • Research becomes fragmented.
  • Creation is simple, but finding and combining is a challenge.
  • Organisation degrades with scale, increasing cognitive burden.
  • Because notes and research are separate, we’re forced to switch context again and again.

Getting interrupted was in the data, supporting the suspicion that it’s the background noise to almost everything else we do. Understanding that the pain experienced by the participants of the market research aligned with my own experiences gave me the confidence to keep building.

While doing research for my literature review:

Our attention spans have shrunk from 2.5 minutes in 2003-2004, to 75 seconds by 2012, and then down again to 47 seconds in the most recent measurements (last 5-6 years).

25 and a half minutes is the average time it takes to return to an original interrupted project after a chain of task-switching.

These figures are the work of psychologist Doctor Gloria Mark from the University of California, who’s spent decades studying people studying.

Interruptions are inevitable, but losing our thread and focus shouldn’t be.

Laying the foundations

Interruptions are also inevitable when we fail to plan, to anticipate, and when we don’t understand the essential prerequisites of entrepreneurship.

Product-Market Fit

Because the ideation and software development phases have coalesced, I’m seeing people launch products without knowing if they’re a fit to a legitimate need that has sufficient market demand.

I’m active on Reddit, and this causal mismatch is a major recurring theme.

As an aside, I built Under Cloud a long time ago, using various versions of it before it had a name. I was the first customer, and hadn’t given much serious thought to making it a commercial product. I’m fortunate in that the market research has such a strong alignment with what I’d discovered while building and using it, but things could have been much different.

So what did I learn?

Building is fast and cheap. Marketing is slow and expensive.

What would I do different?

I’d have done the market research first, and built the product to fit the market, a task that wasn’t as difficult as I imagined it to be.

I’d have built an understanding of the ideal customer profile: their age (range); gender (if applicable); where they live; their budget; their employment status, position, role and so on.

Here, there are three major benefits to building this understanding of the customer and the market:

  1. You’ll have the confidence that there is a known market demand;
  2. You’ll build the product the customer needs and not the one you imagine the customer wants;
  3. You’ll have evidence that the core hypothesis is valid, which should improve conversations with potential partners and investors.

Of course I’ve done these things, but had I known the importance of them when I first began building Under Cloud, I’d have done them a long time ago.

It’s best to build from experience and domain expertise, unless you’re willing to learn (like me)!

James Dyson’s frustration with vacuum cleaners losing suction compelled him to innovations that were disruptive and successful. Dyson was also an engineer.

Me? I’m a visual person, and I couldn’t understand the lack of a product that allowed me to create connections between notes to research, so I began building, iterating, honing, learning, failing, iterating, failing, learning, building…

James and I both had a pain which we learned to understand, and our willingness to explore and create a common analgesic was a good starting point, but we still had to prove there was sufficient demand for our inventions.

You’ll find entrepreneurs are inspired by some sense of frustration and driven by a compulsion to create something to fix it.

Some are altruists. Some are in it to be build and sustain a lifestyle. Some are in for the cash! You’ll need to decide.

As a software solopreneur, you’ll also have to write code…

Vibe coding versus Vibe engineering

Let’s talk about how artificial intelligence and the transformative effect it’s had on software development. Coming at this as a technical entrepreneur, I’ve seen the build phase collapse to the extent that months of intricate and sometimes tedious software development have become mere minutes.

There’s a massive difference between vibe coding and vibe engineering. Without a technical background, the risks are both stark and significant.

AI compounds the benefits of solo founding. As a solo founder, you maintain complete control and start with 100% ownership. This enables faster decisions. It also means you can offer more equity to early team members who become deeply invested while taking less financial and emotional risk.

As a vibe engineer, I’ve benefited from an enormous acceleration in development, also reducing the need to enlist the assistance of domain specialists, keeping the cost of development down. That said, AI is no substitute for good old fashioned human intuition and imagination.

Most AI use a three stage cognitive loop: perceive; plan; and execute. I’ve been using the same loop for the longest time, and the principal benefit is that by documenting this loop, there’s an audit trail of decision making, vital to the AI and me.

Not wanting to be a buzzkill to the vibe, but… anyone operating in the European Union is required to take into account Article 50 of the AI Act.

Without a technical background, that vibe coded app is at best a useful prototype, but it should not be deployed into a production environment until it’s been evaluated by a professional. I’m serious, because the implications of something going wrong could also be serious.

I’ve been reading reports of how confidential data, such as usernames, email addresses, and passwords, have been stored as plain text files as a result of vibe coding.

You want to vibe code? Sigh… then at least do the following:

Instead of using Claude Code or ChatGPT Codex, use Microsoft’s own Visual Studio Code, install the appropriate extension, and generate the code from there. Why? You then own the code, and it’s a legitimate chance to learn and understand that code.

Ask the AI to document the code (also good practice), and use it to understand the structure and the purpose.

Visual Studio Code also supports version control (like track changes in Word), so this would be an excellent time to learn the basic branching strategies.

You’ll be using some type of data storage (a database), so it’s essential you make it safe and secure.

Remember the perceive, plan, and execute pattern? Use that.

An aptitude and an appetite to learn different disciplines

Embrace it, because if the project doesn’t work out, at least you’ll have learned something about software development, and that’s transferable knowledge.

When someone signs up to use our products, we’re entrusted to keep their data safe and secure.

Data sovereignty, residency, and governance

Knowing where our product data is kept and managed are concerns that should be frontmost in the mind of the solopreneur.

Let’s avoid the geopolitical issues and focus on the implications. Also, I’ll come at this from a European perspective.

I’ve created and maintain a Records of Processing Activities (RoPA) document, required by GDPR Article 30:

The General Data Protection Regulation obligates, as per Art. 30 of the GDPR, written documentation and overview of procedures by which personal data are processed. Records of processing activities must include significant information about data processing, including data categories, the group of data subjects, the purpose of the processing and the data recipients. This must be completely made available to authorities upon request.

Yes, it’s boring, but it’s the law, and it’s given me an invaluable situational awareness of the product, where the data is kept, where it goes, and where it’s processed and under what circumstances.

I would also recommend thinking about consent, the use of AI behind the scenes, and the implications to the customer. Under Cloud has a consent section as part of the onboarding flow, where I allow the customer to disable certain AI activities.

It’s important to understand the difference between data sovereignty and data residency, summarised as:

  • Data residency is where the host hardware is kept (nation, region and so on);
  • Data sovereignty is the jurisdiction that has legal access to the hardware hosting the essential resources.

Having an understanding of the data and its cost to me has played a significant role in figuring out how to price the different payment plans.

Pricing the product

You’ll need to begin thinking about a pricing model, but without a good understanding of what things like AI and storage are costing us, our pricing models become guesswork.

Under Cloud has had a cost tracking system in place since the beginning of 2026, and I’ve used that data to build my own pricing model with a good degree of confidence, but I won’t know if that model is reliable until I see an increase in free and paying customers.

Answering the question of price is too much for this discussion, so I recommend following the Van Westendorp Model:

First, the following four questions must be posed at the end of the survey:

  1. At what price would it be so low that you start to question this product’s quality?
  2. At what price do you think this product is starting to be a bargain?
  3. At what price does this product begin to seem expensive?
  4. At what price is this product too expensive?

Getting the pricing wrong could be tolerable at first, but become a major barrier to success in the future.

Success as a solopreneur

My deep dive into the CrunchBase API gave me a total of 7,348 companies that have raised more than $10 million each.

It turns out that almost half of the companies successful in raising funding did so with a solo founder.

I don’t plan on seeking out funding at this stage (Octane is the financial vehicle in that regard), but that hasn’t stopped me from building a sales forecast! Let’s face it, it’s good practice to create and maintain financial documentation because it provides strong awareness, assuming the numbers are valid. Also, it’s demonstrative of having an understanding of the market.

Final thoughts…

I’ve been working alone for almost three decades (as Octane and then with Under Cloud), and I suspect most couldn’t handle that. But there’s a difference between alone and loneliness.

We solopreneurs must be versatile and agile, and learn to take what to everyone else is a struggle and transform it into a superpower.

AI has enabled people like us to automate to such an extent that it’s almost like having a team — virtual, of course. But the caveat here is the assumption that the use of AI is judicious, alloyed with strong critical thinking.

Going it alone isn’t always a choice but it is now a viable alternative to finding a co-founder and the challenges such arrangements bring.

I do hope this article has been useful, and feel free to share it!

We experience the world as connections — between things like important people, memorable places, and historical events. Explore the original article as a knowledge graph, to read the sources I’ve referenced in this article.