Examples of my fractional CTO work

The following article was first published on LinkedIn:

Hiring a developer to be your CTO can lead to failure - consider a fractional CTO

June 6, 2023

Over the past ten years, the option of a part-time or fractional CTO has become more popular.  A fractional CTO addresses a problem that has plagued early-stage (first 5-8 years) startups for decades; a permanent CTO is expensive and often not needed full-time.  But why is a CTO needed at all in the early stages of a business?

It’s very easy for non-technical founders to fall into the trap of either hiring a developer to produce an MVP (minimum viable product) or outsourcing the development of an MVP to a developing country with “cheap” developer resources.  

A good developer will typically know how to take your requirements and implement them in code. However, that is just one small part of taking an idea into a working product, and there are many potential pitfalls along the way.  I have had to rescue many startups that have floundered because of only having developers and no technical leadership, strategy or oversight.  

Here are some of the problems I have encountered when a developer or a team of developers are working without a CTO or other technology leadership:

1. A developer needs a good set of requirements/user stories.  Non-technical founders often struggle to articulate their needs fully and in a way in which developers can understand.  They may leave out details which they assume will go in, and they also have a tendency to think they need a lot more features to launch or sell a product than they do.  A good fractional CTO will get the core ideas out of a founder, turn them into actionable statements and gets the best version of a product built.  In my experience, I’ve seen MVPs built that don’t do what the founder wanted leading to frustrations. Other times the project has taken a lot longer and been a lot more expensive because the founder keeps going back to adjust (in a non-agile way).  One mobile app I became involved in ended up taking an Indian outsourcing team 18 months to complete instead of three months because of this very issue.  By the time the application was ready, the product had started to lose its uniqueness because other entrepreneurs had spotted the problem they were trying to solve and had started releasing solutions.

2. Choosing the right stack - by stack, I mean the end-to-end technology choices that need to be made when building an application - is by no means simple.  This includes the choice of programming language(s), frameworks, third-party libraries, integrations and other vendors.  I’ve joined startups three years in who have suffered from making the wrong choices early on because the developer they hired chose a stack they ‘liked’ and not because it was the best solution to the problem they were solving.  The kinds of problems this can cause include choosing a stack that is hard to recruit for, choosing a stack that has a lot of bad devs in its community and therefore ending up with bad devs, choosing buggy libraries or third-party apps that are embedded on integrated into the app that are no longer supported.  Another strategic decision a CTO might make it Buy vs Build.  When building new features, there are often choices to either write something yourself or buy something that already exists and integrate it.  It’s not always an obvious choice and some developers are prone to reinventing the wheel.

READ MORE