Back to Blog

Fundraising • Engineering • Leadership

Your First 90 Days After Raising: A Technical Playbook

You have the money. The clock is ticking. Here is how to spend your first three months making technical decisions that will either accelerate your startup or sink it.

Mike Tempest • 12 min read •

Congratulations. You have just closed your seed or Series A. The wire has landed, the champagne is flat, and now you are staring at a bank balance that feels both enormous and terrifyingly finite. Your investors expect execution, not exploration. They did not back you to spend six months "figuring things out."

If you are a non-technical founder, the technology side of your business probably feels like a black box. You have a product that works (mostly), built by freelancers or a small team, and you know it needs to scale. But you are not sure what "scale" actually means in practice, or where to start.

This is the playbook I wish someone had given me. After years as a CTO building and scaling products, and now as a Fractional CPTO advising post-raise startups, I have seen the same patterns play out dozens of times. The founders who get the first 90 days right build momentum that compounds. Those who get it wrong spend 12 months recovering.

Here is how to get it right.

Days 1 to 30: Audit, Understand, Resist the Urge to Hire

Your first instinct will be to start hiring immediately. Fight it. You cannot build a team if you do not understand what you are building on.

Get an honest technical assessment

Before anything else, you need to know the real state of your technology. Not what your developers tell you (they are too close to it), and not what your pitch deck says (that was written to raise money). You need an independent, honest technical audit.

This does not mean hiring a consultancy to produce a 50-page report. It means getting someone experienced to spend a day or two looking at your codebase, your infrastructure, and your development processes. They should answer three questions:

1. What do we actually have?

Is the codebase maintainable? Are there automated tests? Can someone other than the original developer deploy it? How much is documented versus living in someone's head?

2. What will break first?

Every early-stage codebase has weak points. The question is whether those weak points are in the path of growth. A messy admin panel is fine. A database that cannot handle 10x your current load is not.

3. What is the team actually capable of?

Be honest about skill levels. A team of junior freelancers who built your MVP may not be the team that scales it. That is not a criticism; it is a reality you need to plan around.

Questions to ask your development team

You do not need to understand code to ask good questions. Here are the ones that matter:

  • + "How long does it take to deploy a change to production?" If the answer is more than a few hours, your deployment process needs attention. If it involves manual steps, it is fragile.
  • + "What happens if our user count doubles next month?" You want specific, technical answers. "It would be fine" is not good enough. "The database would need a larger instance and we would need to add caching to these three endpoints" is.
  • + "What is the thing that worries you most about our codebase?" Good developers know where the bodies are buried. Give them permission to be honest and they will tell you.
  • + "If you left tomorrow, how long would it take someone to pick this up?" The answer reveals both documentation quality and bus-factor risk.

Do not hire yet

This is the hardest advice for founders who just raised. You have capital and ambition, and hiring feels like progress. But hiring before you understand your technical landscape means you will hire the wrong people for the wrong roles. Spend month one listening and learning. The hiring decisions in month two will be dramatically better for it.

If you want a deeper dive on building your first engineering team, I have written a separate guide on the topic.

Days 31 to 60: Your First Technical Hire

This hire matters more than you think. Get it right and you have a foundation. Get it wrong and you have lost three to six months.

CTO vs senior engineer vs fractional CPTO

The temptation is to hire a CTO. You are a non-technical founder, so obviously you need a technical co-founder figure, right? Not necessarily. The right hire depends on your stage and what you learned in month one.

Full-time CTO

When it makes sense: You have proven product-market fit, you need to build a team of five or more engineers in the next 12 months, and you have the budget for a £120k to £180k salary plus equity. A CTO at this stage is a leader who builds teams and sets technical direction.

The risk: Most seed-stage startups do not actually need this. Hiring a CTO too early means paying a leadership salary for someone who spends 80 percent of their time writing code because there is no team to lead yet. That is an expensive engineer. The question of when you actually need a CTO is worth thinking about carefully.

Senior engineer

When it makes sense: Your technical audit revealed a codebase that is fundamentally sound but needs more hands. You need someone who can ship features, mentor junior developers, and improve code quality. Budget: £70k to £100k.

The risk: A senior engineer is not a technical leader. They will not set your architecture strategy, manage vendor relationships, or advise on build-versus-buy decisions. If you hire a senior engineer expecting CTO-level strategic thinking, you will be disappointed. For guidance on what to look for in your first engineering hire, the details matter.

Fractional CPTO

When it makes sense: You need senior technical leadership to set direction, make architecture decisions, and help you hire, but you do not have enough work (or budget) for a full-time executive. A fractional CPTO typically works one to two days per week, giving you experienced guidance while you build.

The risk: Minimal, provided you find someone with genuine operating experience. The fractional model lets you access senior talent at a fraction of the full-time cost, and you can scale up to full-time if the relationship works. It is increasingly the smart play for post-seed startups.

The cost of getting this wrong

A mis-hire at this level does not just cost salary. A wrong CTO will make architecture decisions you will live with for years, hire people in their own image (who may not be what you need), and set cultural norms that are hard to reverse. I have seen startups lose 12 months of runway unwinding a bad senior technical hire. At seed stage, that can be fatal.

Take your time. Talk to at least ten candidates before making an offer. Get a technical advisor to sit in on interviews if you are not technical yourself. The right hire at this stage compounds; the wrong one compounds too, just in the wrong direction.

Days 61 to 90: Architecture Decisions That Will Haunt You (or Save You)

By now you have a clear picture of your technology and either a new hire or external support. Time to make the decisions that shape the next two years.

Build vs buy

Every feature request creates this choice. Build it yourself or pay for an existing solution? The default for most engineering teams is to build, because building is more interesting than integrating. But interesting is not the same as smart. We have written a detailed build vs buy framework that covers this decision in depth.

The rule of thumb: If it is not your core differentiator, buy it. Authentication? Use Auth0 or Clerk. Payments? Stripe. Email? SendGrid. Monitoring? Datadog. Your engineering team's time is your most expensive and most limited resource. Spend it on the things that make your product unique, not on reinventing infrastructure that someone else has already perfected.

The exception is when the bought solution creates a dependency that limits your product. If your core value proposition depends on sending emails in a very specific way, maybe you do build your own email pipeline. But be honest about whether that is truly the case.

Monolith vs microservices

I will save you months of debate: start with a monolith. Or rather, keep your monolith. If your current product is a single application, do not break it apart into microservices. Not yet. Probably not for a long time.

Microservices solve a specific problem: they allow large teams (20 or more engineers) to work independently on different parts of a system. If you have fewer than ten engineers, microservices add complexity without any of the benefits. You will spend more time managing inter-service communication, deployment orchestration, and distributed debugging than you will save in development speed.

The companies that successfully run microservices all started with monoliths. They extracted services later, when they had clear reasons to do so and the team size to support it. Follow their path, not their destination.

Tech debt trade-offs

Your technical debt did not disappear when the money landed. But now you have the resources to address it strategically. The key word is "strategically," not "comprehensively."

Categorise your tech debt into three buckets:

Blocking debt

Debt that will prevent you from scaling. A database that cannot handle growth, a deployment process that takes a full day, authentication that is not secure enough for enterprise customers. Fix this now.

Slowing debt

Debt that makes the team slower but does not prevent progress. Messy code in frequently changed areas, missing tests for critical paths, manual processes that could be automated. Address this incrementally, allocating 15 to 20 percent of each sprint to paying it down.

Cosmetic debt

Debt that offends developers but does not affect the business. Inconsistent naming conventions, old libraries that still work, code that is ugly but functional. Ignore this entirely until you have nothing more important to do. You always will.

5 Mistakes That Burn Through Post-Raise Runway

1. Hiring too fast

The pressure to "deploy capital" leads founders to hire three engineers in month one. Without proper onboarding, clear architecture, and management processes, those engineers will spend their first three months stepping on each other's toes. Hire one person at a time. Let them settle before hiring the next. A team of three productive engineers beats a team of six confused ones.

2. Rewriting everything from scratch

"Now that we have money, let's rebuild the whole thing properly." This sentence has destroyed more startups than bad code ever has. A rewrite means months of zero feature development while your competitors move. It means re-introducing bugs that were already fixed. It means your new hires are building something they have never seen work rather than improving something that already does. Refactor incrementally. Rewrite only as a last resort.

3. Chasing shiny technology

Your new CTO wants to rewrite the backend in Rust. A developer read a blog post about event sourcing and thinks it would be "perfect for us." Someone suggests moving to Kubernetes. Unless these technologies solve a specific, measurable problem you have today, they are distractions. Boring technology that works is infinitely better than exciting technology that might work eventually. Choose tools your team already knows well.

4. Ignoring security until something goes wrong

"We'll sort security out later" is the startup equivalent of "we'll buy insurance after the house burns down." At minimum, within your first 90 days, ensure: all data is encrypted in transit and at rest, authentication follows current best practices, you have audit logs for sensitive operations, and someone has checked for the OWASP Top 10 vulnerabilities. A data breach at seed stage is not just embarrassing; it can be company-ending.

5. Building features nobody asked for

With money in the bank, it is tempting to build the roadmap you pitched to investors. But that roadmap was a hypothesis. Before building, validate. Talk to customers. Look at usage data. The features that feel obvious from the boardroom are often irrelevant in practice. Your first 90 days should produce a handful of well-validated features, not a sprawling product that nobody fully uses.

When to Bring in Outside Help

Not every founder needs to navigate this alone. In fact, trying to figure out technology strategy without technical experience is one of the most expensive mistakes you can make. You would not do your own legal work or audit your own books. Technology strategy deserves the same respect.

A Fractional CPTO can be particularly valuable in the first 90 days because they bring pattern recognition. They have seen dozens of post-raise startups, know which problems are urgent and which can wait, and can help you avoid the mistakes that cost time and money.

Consider outside technical leadership if:

  • + You are a non-technical founder making technical decisions that will shape the next two years of your company
  • + Your current team is junior and you need someone to set architectural direction and mentor them
  • + You are about to make your first senior technical hire and want someone experienced to help you assess candidates
  • + Your investors are asking technical questions you cannot answer and you need credible technical representation in board meetings
  • + You feel the pressure to "move fast" but are not sure which direction is forward, a common and understandable position after raising

The first 90 days after raising are when the trajectory of your technical organisation is set. The decisions you make now, about people, architecture, and priorities, will compound over the next 18 months. Getting experienced input at this stage is not a luxury; it is an investment in getting those decisions right.

The Bottom Line

The first 90 days after raising are not about building fast. They are about building right. Understand what you have before you change it. Hire carefully, not quickly. Make architecture decisions based on where you are, not where you hope to be in three years.

The founders who use this window well emerge with a clear technology roadmap, the right people in place, and a codebase that is ready to scale. The founders who waste it emerge with a bloated team, a half-finished rewrite, and a board that is starting to ask uncomfortable questions.

Your investors backed you because they believe in the opportunity. The first 90 days are where you prove that belief was well placed. Make them count.

Related Articles

LeadershipEngineering

How to Evaluate Your Engineering Team as a Non-Technical Founder

You do not need to read code to know whether your engineering team is healthy. 7 signals of a healthy team, 5 red flags, and a practical monthly health check framework for non-technical founders.

10 min read
StrategyEngineeringLeadership

How to Build a Technology Roadmap for Your Startup (Without a CTO)

Most startup roadmaps are feature lists, not strategy. A practical three-layer framework for non-technical founders to build a technology roadmap that connects business goals to technical delivery.

11 min read
EngineeringLeadership

When to Move from Dev Agency to In-House Engineering

Five signs you have outgrown your dev agency, what the transition actually looks like, and how to avoid the mistakes that cost startups months of momentum.

9 min read

Just raised? Let's get your first 90 days right.

I work with post-raise founders as a Fractional CPTO, helping you make the technical decisions that set the trajectory for the next 18 months. Start with a free strategy day.

Book a Free Day Get in Touch

Frequently Asked Questions

Should I hire a CTO immediately after raising my seed round?

Almost certainly not. Spend your first 30 days understanding what you actually have before making any senior hires. A bad CTO hire at this stage can cost you 6 to 12 months of runway between salary, mis-hires they make, and wrong technical decisions. Understand your technical landscape first, then decide whether you need a full-time CTO, a senior engineer, or a fractional CPTO.

How do I assess the quality of code my freelancers have built?

You do not need to read the code yourself. Bring in an independent technical person for a day or two to review the codebase. Ask them three things: can a new developer understand this code without the original author? Are there automated tests? Can it be deployed without manual steps? If the answer to all three is no, you have a problem, but it is usually fixable if caught early.

What is the difference between a CTO and a fractional CPTO?

A full-time CTO is a permanent executive who owns your entire technical strategy and team. A fractional CPTO gives you the same strategic leadership on a part-time basis, typically one to two days per week. For post-seed startups with small engineering teams, a fractional CPTO often makes more sense because you get senior experience without the £150k to £200k salary commitment.

Should I rebuild my MVP after raising?

Rarely. Most MVPs have problems, but a full rewrite is almost never the right first move. It burns months of runway, delivers zero new value to customers, and often introduces new bugs while fixing old ones. Instead, identify the specific parts that will not scale and address those incrementally. A complete rewrite should be the last resort, not the first instinct.

How much of my seed round should go to engineering?

There is no universal ratio, but for a technology startup, engineering typically accounts for 40 to 60 percent of seed spending. The more important question is whether that spend is creating durable technical assets or just burning cash on features nobody uses. Every engineering pound should map to a business outcome you can measure.

Mike Tempest

Mike Tempest

Fractional CPTO

Mike works with post-raise startups as a Fractional CPTO, helping non-technical founders make the technical decisions that shape their companies. As Head of Engineering, he scaled RefME from 0 to 2M users, and as CTO turned Risika profitable in 18 months. He has been through the first 90 days more times than he can count, on both sides of the table.

Learn more about Mike