Building the technology function for a high-growth marketplace

Business context

A Series B marketplace platform connecting service providers with consumers was experiencing the growing pains typical of fast-scaling businesses. The platform worked — transactions were flowing, the customer base was expanding, and the unit economics were improving. But the technology underneath was struggling to keep up.

The company had been founded by commercially-minded operators who had built the initial platform with a small contract development team. That approach had served them well through product-market fit and early growth, but as the business scaled beyond 50 employees and transaction volume multiplied, the cracks were showing. Deployments were risky and infrequent, outages during peak periods were eroding provider trust, and the founding team had no internal technology leadership to guide the next phase.

The board recognised that the technology function needed to mature significantly before the business could credibly pursue Series C funding — and that this couldn’t happen without experienced technology leadership.

The challenge

The immediate challenges were operational: improve platform stability, reduce deployment risk, and establish basic engineering practices. But the real challenge was structural — the business needed a technology function that could operate independently, attract good engineers, and scale with the business.

There was no CTO, no engineering manager, no formal architecture, no CI/CD pipeline, no monitoring to speak of, and no documentation. The existing development team of four was talented but overwhelmed — simultaneously building features, fixing production issues, and trying to keep the lights on. Without intervention, the business would hit its Series C raise with a technology story that investors would not fund.

My role

Fractional CTO, initially at three days per week, with a mandate to build the technology function from the ground up. This was not an advisory engagement — it was hands-on technology leadership, with accountability for stability, architecture, hiring, and board reporting.

What I did

Stabilisation (months 1–2). The first priority was stopping the bleeding. Introduced basic observability using Datadog, established an incident response process, and identified the three architectural weaknesses responsible for most outages. The critical reliability issues were resolved within the first six weeks, bringing uptime from 97.2% to 99.5%.

Architecture redesign (months 2–5). Working with the existing team, redesigned the platform architecture to support the next phase of growth. This included migrating from a single monolithic application to a set of well-bounded services, introducing proper caching with Redis, redesigning the database schema to handle concurrent transactions more effectively, and implementing a CI/CD pipeline using GitHub Actions. The goal wasn’t architectural perfection — it was removing the constraints that were limiting the business.

Team building (months 3–9). Designed and ran a structured hiring process to scale the engineering team from 4 to 18. This included defining role levels and career progression, writing job descriptions that attracted the right candidates, conducting technical interviews, and establishing onboarding practices. Also hired the company’s first dedicated QA engineer and first DevOps engineer — both roles critical to sustaining quality as the team grew.

Every hire was evaluated not just on technical ability but on their capacity to contribute to a self-sustaining engineering culture. The goal was a team that could operate without me.

Engineering practices. Established the practices that would become the team’s operating rhythm: code review standards, sprint planning, retrospectives, architecture decision records, and a production readiness checklist. None of this was revolutionary — but it was systematic, and it gave a fast-growing team the structure needed to move quickly without breaking things.

Board and investor engagement. As the business prepared for Series C, worked with the CEO to articulate the technology strategy in terms that resonated with investors. This included preparing technology due diligence materials, presenting the architecture roadmap, and demonstrating that the engineering team was now a capability — not a liability — in the fundraising narrative.

Systems and platforms

AWS as the core infrastructure layer; Node.js and React for the application stack; PostgreSQL for the primary database with Redis for caching and session management; GitHub Actions for CI/CD; Datadog for observability, alerting, and incident management.

The stack was kept deliberately conventional — well-understood technologies with deep hiring pools, mature tooling, and strong community support. In a fast-scaling team, boring technology is a feature.

Outcomes

Platform uptime improved from 97.2% to 99.95% over the engagement period. Deployment frequency went from fortnightly (at best) to multiple times daily. The architecture was redesigned to support 10x transaction volume without re-platforming. The engineering team scaled from 4 to 18 with a structured hiring process and clear career progression. The business established its first dedicated QA and DevOps capability.

After twelve months, the technology function was operating independently. The Series C raise included technology due diligence that reflected a credible, well-run engineering organisation. The transition to a monthly advisory arrangement and eventual full handover was always the plan — and it executed cleanly.