Building a Software Product Without a Tech Co-Founder

In the past month, I’ve been lucky enough to be introduced to quite a number of startup founders in London, many of whom were on the lookout for a tech co-founder.

Some had already realised the search for that co-founder could take a while, and so they sensibly asked for tips on how to build a software product without one. This article is my attempt to summarise what usually became a very long answer to that question!

Firstly, unless you’re planning to build the product entirely yourself — which is certainly possible if you have the time and appetite to learn — the following answer relates to building it with the help of software developers; either in-house or freelancers. It covers starting points for the things I think you should understand and do that a tech co-founder might normally cover. My own view is that you should eventually find (or promote) someone to cover all of this for you but, in the interim, this answer might help you to bridge the gap or at least help you discuss topics with developers.

It’s worth taking a look at the situations most non-tech founders are trying to avoid or have already found themselves in, when building a software product:

• Feeling a loss of control over precisely what the product becomes, despite being the ultimate product owner.
• Feeling unable to contribute to technical decisions that dictate precisely how the product works, how much it costs to build, deploy and run.
• Having developers leave and take much of the internal product knowledge with them in their heads.
• Encountering production problems out-of-hours — perhaps even being unaware of them — and being unsure how to resolve them so they don’t occur again.
• Wanting to do things such as moving cloud providers but not knowing enough to discuss the specifics, to steer decisions and to undertake such a complex technical change.

My answer tends to hinge upon ways to avoid or minimise these problems, but I also threw in some further topics I think you should strive to understand if you lack a tech co-founder, to get the best results. You won’t be covering them all initially, but they might give you a sense of where your gaps are.

Finally, this answer could have been twice as long and still be considered incomplete. I have necessarily missed many things out and only hinted at others. See it as a starting point for your own exploration, or as a list of things to discuss with a potential tech co-founder.

PICK YOUR BATTLES, BY LAYER

It’s a safe assumption that you don’t have enough time to do everything a tech co-founder would for your company. A tech product is a many-layered thing and so you should probably aim to focus your efforts on certain layers more than others. (You can still steer and ask about the layers you have chosen to pay less attention to). Trying to understand everything yourself is a recipe for exhaustion.

• (High Focus) Customer-Facing: User eXperience (UX) & User Interfaces (UI) — You should want to understand, drive or at least have an overview of all topics in this layer in the early days, albeit delegating to Product, UX and UI experts where possible. Even with a tech co-founder, you would very likely have focussed on this layer of your product anyway.
• (High Focus) Data: Gathered & Derived — Most people think data is a distinctly hidden part of a software product but, without it, there would be nothing to surface in the UI, leaving those mock-ups looking rather pointless. You should understand the data you are gathering from customers and obtaining from third parties. You should also have a firm understanding of any data you generate via various algorithms, perhaps some even as complex as Machine Learning / AI, though the details of exactly how you’re doing that should probably be left to developers.
  This data awareness allows you to think through product scenarios, armed with the specifics upon which they depend. Without that, you will likely try to take your product in directions that a lack of data doesn’t allow, or where obtaining that data (from a third party or via calculation / derivation) is hard or costly.
  When you draw UX/UI mock-ups, annotate them with where the data comes from or how you plan to obtain it. Encourage other people in the company to be data-aware too; it makes product conversations much more productive.
• (Medium Focus) Architecture: Applications, APIs & Services — This layer captures the other non-visible aspects of your product and covers the terminology in which you should expect to discuss it with developers to drive it forward. Whilst your developers will lead these aspects, and they should, using their experience to propose architectural solutions to satisfy the external-facing needs of your product, you should aim to have a decent grasp of at least the overall architecture so you can understand and steer where they are going.
  They should be able to point to the architecture, or a proposed change to the architecture, to explain almost any task they are working on, so use it as a discussion point.
• (Medium Focus) Infrastructure, Environments, Deployments — This is also a layer you should dip into sufficiently to understand how and where your product runs, how many environments you have (Development, QA, Production, etc), what they are used for and how they are organised. Decisions made in this layer affect the cost of your deployments, your product’s resilience in production and the processes you use to release and upgrade it.
  As with architecture, this is a layer you should aim to understand in sufficient detail to drive and take part in discussions, so that you understand what you own. Again, decent developers will be able to lead you, but you need to be able to discuss what they are recommending.
  This is also an area in which you may want some ad-hoc help from experts on issues such as security, cloud deployments, etc, if only to give you the assurance that things are solid and remain so.
• (Low Focus) Detail, Code, Programming Languages — This is the layer you should choose to avoid unless you really have the time / interest to dig in. In essence, the code should represent an implementation of the concepts you are discussing as architecture (see earlier point), so everything here should be accountable for by your developers in those terms; if not, ask them how the thing they are building relates to the architecture, and impress upon them the need to build what you agreed and to discuss the need for anything else.
  When it comes to the actual code, learning to code well is not a small undertaking, despite many online courses that only teach you to write some code claiming otherwise.
  Learning informally to read code is another thing altogether, and something you might pick up in talking to developers and having them show you their work. Leave the coding detail to your developers, however. Using a combination of their deeper tech knowledge, the source code they write for you, and the docs / wiki pages I’ll encourage you to get them to write (see later), most developers will be able to handle this layer for you and (equally as crucial) explain it to you in language that you understand.

RETAINING OWNERSHIP: STEER AND UNDERSTAND

The biggest concern founders expressed was losing control of the direction of development and not understanding what had been built. It is very easy to find yourself with something that is, strictly speaking, what you asked for but of which you don’t understand any of the underlying details.

A useful idea is to define the desired outcome in conjunction with a developer (work gets agreed up-front), then get them to break it down into stages / chunks of, say, 1–3 days duration and explain how they will convince you at each stage that it is complete and works as intended (progress is visible and understandable). This puts the onus on the developer to convince you, in your language, where they are going and what they built. Crucially, it strikes a middle ground that gives you insight and control while still empowering them to build the best they can for you. You may even find they relish the discussion and the focus on what they can potentially achieve. Developers love to talk about tech, so let them!

Transparency — It is important that you can have open and honest conversations with your developers. If you get the sense that they are covering up mistakes or aren’t being completely transparent — sometimes very human traits, but not very helpful to your business — make it clear to them what you expect and that you are trying to get the best result, in conjunction with them, rather than just questioning their skills. It’s all about the result you’ll achieve together and radical transparency helps hugely.

Intellectual Property (IP) — Your IP isn’t just your source code; albeit that’s where the legal definition probably stops unless you also have patents. It’s also your architecture, your systems / processes and it is only usable to the extent that you can access it and understand it. It should not all be in your developers’ heads. (See next point for docs / architecture).
Your source code should be in a repository such as Github and even unfinished work should be committed there, perhaps on a branch to be merged after review (see Quality).

Grow a Wiki — A wiki acts as a focal point via which you capture and refine the artefacts (docs, diagrams etc) forming the non-code aspects of your IP. Even an incomplete wiki is better than none. Rather than sporadically updating it every few months, make it part of your company culture to refer to info on the wiki rather than exchanging it verbally or via email.
If you’re about to say something complex verbally, encourage drafting it on the wiki and using that. If you are about to send a long and complex email, encourage sending a link to a wiki page. What this does is retain the info so you can improve and expand up on it later. It also means you can send it to the next person / new hire / etc and improve upon it later. Emails, chat and verbal conversations are lost. A wiki will be there forever.
It is worth pointing out that a wiki doesn’t have to take ages to update. Diagrams can be snapshots of a whiteboard. Documents can be outlines that get gradually filled in. No Picassos or Shakespeares required!

BAKE QUALITY IN

Standards, code reviews, peer reviews — You may not understand the details here, but you should mandate that developers are following some well-defined standards for the language they are coding in and are peer reviewing their code. They should be able to explain to you why this is a good idea. If they can’t, you might have the wrong developers.

Build — Your product build should be automated to require execution of a single command and that procedure should be written on the wiki so anyone can do it. If it takes more than one command, question why. Repeatability reduces mistakes.

CI — You should set up some form of Continuous Integration (CI) to run your build and all automated tests, and you should be interested in the % of test coverage your developers have achieved (the portion of your source code that is exercised by automated tests). Beyond a certain point, further code coverage gives limited returns, but the goal should always be to maintain or improve upon it with each commit so that accidentally introduced bugs stand a chance of being picked up as early as possible.

CD — If possible, some form of Continuous Deployment (CD) should be used to migrate your latest builds into a shared Dev or QA environment. This means you always have a view of the latest state of your product, and perhaps somewhere to demo it from. CD can also be used to prepare your build for deployment to production, but you’ll want to keep a tighter control on how and when those upgrades occur, perhaps at least requiring a human to push a final button when you choose to do them.

CI and CD automate much of the pipeline between committed code, test execution and your environments. You may start out doing much of this manually but, to avoid mistakes, you should try to automate it as soon as possible. Tools such as Jenkins can help.

CULTURAL: COMMUNICATION AND TRANSPARENCY

Help developers to understand your business and, in turn, enlist their help in making sure you understand at least the above layers of tech yourself. Make a point of encouraging transparency with regular show-and-tell sessions between tech and non-tech parts of the company. Get everyone used to talking in one other’s language, even if they struggle at first. It will make each person feel involved in the business as a whole.

Some developers have a habit of self isolating, so don’t let that happen; engage them in your business actively. Ensure developers expose their decisions, architecture etc on your wiki so the entire company can see and contribute feedback. They may initially resist this, but they will probably eventually relish the chance to show off their work and to discuss it.

Making and Revisiting Decisions — Use the wiki to document complex technical decisions, such as which cloud provider you use, how you implemented login security, the programming language you chose, etc.
I find it useful to list off the criteria against which a decision with various possible options will be assessed. Let everyone involved list off those criteria (How does it perform? How many database calls does it make? etc), then for each possible option answer those criteria and compare the answers.
This makes it clear which option is “best”, for you, and why you made the overall decision you made.
Importantly, you can return to decisions later, in light of new information, and determine whether to change your mind.
Structuring and capturing complex tech decisions like this makes them easier, broadens understanding and creates a sense of transparency and cohesion around them. It tends to stop the urge to revisit the same old decision again and again (“Why are we on AWS?!”)

PRODUCTION ISSUES: WHAT DO WE DO WHEN IT FAILS AT 3AM?

The unexpected will happen — Sooner or later, no matter how rock-solid your product is, it will fail in production… and probably at 3am. Something unexpected will go wrong.
Good developers don’t just code for the “happy path” (the one that encounters no problems). They code defensively for the unexpected and think about how problems should be handled when they eventually occur. This is something you may need to encourage and ask them how they have accommodated for it in the code, architecture, processes, etc. Do not just assume it is being handled.

Data & Analytics — Your product should log and capture enough information to allow you to determine how it is running, whether it is even running(!), and what happened in the event of a failure. This could be written to log files collated somewhere (there are plenty of cloud-based options), or as additional attributes captured via an analytics product (again, lots of options there).
Even when things are going well, this data will give you insight in to the otherwise-invisible world of your product: What customers are doing, how the system is running, how close to scaling capacity you are.
Without analytics and data, you are flying blind which isn’t ideal even when things are going well, but is lethal when things eventually go wrong. And they will occasionally.

Knowing something went wrong — Knowing that something went wrong can begin as simply as making use of a tool to monitor your website / product for outages. But you should expand upon that to monitor the health of your product in other areas: Memory usage, disk space, database capacity, errors being thrown, etc.
For all of those metrics, make use of your cloud / other provider’s alarm functionality so you are alerted (text or pager) in the event that a problem occurs.
You should not rely on a customer telling you that they had a problem. By the time they call you, you should already know.

What do we do when something goes wrong? — Some form of off-the-shelf issue tracking system is a wise investment, and preferably one the includes a way to text / page you and your team. It should help you define a support rota and an escalation path in the event that no one responds to the issue (it pages a developer, then it pages you if they don’t respond).
Your wiki should eventually contain “run books” describing how to triage a new problem (assess impact, categorise) and how to perform common tasks: Check if a system needs restarting, perform the restart, check it is up and running again.
Everyone on the support rota (which may go beyond just the tech team in a small startup) should have access to the systems they are supporting, and simple instructions on how to do basic support tasks. Spreading the responsibility and making production support a shared task, rather than the burden of a few developers, will increase the appetite to genuinely solve those problems before they happen again (see next point).

Root-cause analysis — It is tempting, once a production issue is resolved, to breathe a sigh of relief and to return to whatever you were doing. But you need to find out why the problem occurred and, even more crucially, the root cause behind it so you can prevent it from happening again.
Employing the “5 Whys” analysis technique can help you here: Why did it fail? The database filled up. Why did that happen? We didn’t notice it reached capacity. Why? We have no alarming on that… so we’ll add it.
Encourage strict logging of issues for problems / outages, so they can be investigated more calmly in this way once the alarm bells and pagers have stopped sounding.

As I said at the start, there is a lot to cover if you don’t have a tech co-founder and are building a software product. The above has only been a list of entry points, and a large one at that.

My strong opinion is that you should seek a tech co-founder at some point, or at least a regular advisor, but practicalities may dictate you go without one for a while, perhaps even long-term. If so, I hope the above gives some sense of the landscape you should strive to understand, cover and effectively lead your company through.

The rest, I think you discover as you go, in conjunction with your developers. Empower them to help you steer them and understand their work. You may just find that one of them eventually becomes the tech co-founder or tech lead you were looking for all along!