Transport-tech startup · 3.5 years · sole Engineering Manager

One engineer, a blank page, and a platform moving children. 3.5 years, 99.5%+ uptime.

Live GPS tracking and safeguarding compliance for a service moving children, built and run by one person from nothing — where every architecture choice was also a maintenance choice, made by the person who'd be maintaining it.

The situation

A transport-tech startup needed a platform to move children safely, with live location visibility for parents and operators, and safeguarding compliance built in from day one — not bolted on once someone asked about it. Nate joined as sole Engineering Manager and owned the entire technical function from a blank page: no existing codebase, no team to inherit, no prior architecture to work around. Just the problem, and 3.5 years to build and run the answer.

Constraints

Being the only engineer isn't a staffing footnote here — it's the constraint that shaped every other decision:

  • Sole engineer, forever. Every architecture choice was also a maintenance choice. There was no team to absorb a bad decision's ongoing cost — the person choosing the stack was the person who'd be on call for it three years later.
  • Safety-critical domain. This is a platform moving children. Safeguarding compliance isn't a feature you can ship in v2 — it's a precondition, and it changes what "done" means for practically every part of the data model.
  • Startup economics. Cloud spend is runway. An architecture that's technically elegant but expensive to run isn't neutral in a startup — it's actively shortening the company's life.

Architecture decisions — and why

The backend ran on serverless Firebase. For a team of one, this isn't a trend choice — it's the only choice that keeps operational load proportional to one person's available hours. Zero-ops infrastructure and a scale-to-zero cost profile mean the platform doesn't need a 3am pager rotation that doesn't exist, and doesn't burn runway sitting idle between usage spikes. The constraint (sole engineer, startup economics) selects the architecture directly.

Dual Flutter apps from one codebase — driver-facing and parent-facing — gave both apps behavioral and visual parity without doubling the surface area one person has to maintain. Every bug fixed, fixed twice. Every platform update, handled once. That single decision is most of the reason 3.5 years of solo maintenance was survivable at all.

A Next.js operations portal existed because the real day-to-day user of a children's transport platform isn't the parent checking a map — it's the operations team running routes, handling exceptions, and responding when something needs a human. Building that portal as a first-class product, not an internal afterthought, is what made the platform actually operable.

The real-time GPS pipeline and the safeguarding data model were designed together, not sequentially — because retrofitting compliance is the expensive path. Safeguarding requirements shape what data you capture, how long you retain it, who can see it, and how it's audited. Baking those constraints into the schema from day one is cheaper by an order of magnitude than adding them after the data model already exists and half the app already assumes the old shape.

Stack

FlutterNext.jsFirebaseReal-time GPSGCP

What shipped

The entire technical function of the company: dual mobile apps (driver and parent), an internal operations portal, a serverless backend, real-time GPS tracking, and safeguarding compliance woven through the data model from the start. Built, deployed, and operated solo for 3.5 years.

Measured outcomes

99.5%+ uptimeon a safety-critical platform, sustained over 3.5 years
~60% faster releasesas the architecture and pipeline matured
~30% lower cloud costthrough continuous optimization, not a one-off cut

Boring infrastructure is how one engineer sustains 99.5% uptime on a safety-critical system.

Lessons

Release speed turned out to be an architecture property, not a discipline problem. The ~60% improvement in release speed didn't come from working faster — it came from a serverless, scale-to-zero foundation that made most releases low-risk by construction, so the process around them could get lighter without getting less safe.

Cost optimization worked the same way: not a single migration event, but a continuous practice enabled by an architecture that made waste visible and cheap to fix. The ~30% cost reduction accumulated the way compound interest does — small corrections, made often, on infrastructure simple enough that a solo engineer could actually see where the money was going.


Considering handing your product to one person full-time, or wondering what a solo build could sustainably support? We've run this exact model for 3.5 years — happy to talk through what it takes.

Fixed quote within 48 hours — no obligation.