Waave

Context

I was CTO of Waave from 2019 to 2025, working out of New York and Boston. Waave is a taxi platform, and a taxi platform in the United States runs into a fact that software people usually never meet: a taximeter is a legal measuring instrument, the same category as a fuel pump or a supermarket scale. It is regulated by weights and measures authorities, and the route to being allowed to charge a fare with it goes through the National Type Evaluation Program.

Most platforms sidestep this by putting a certified hardware meter in every car and letting the app be a nice interface on top. That works. It also puts a hardware unit cost, an installation cost and a maintenance cost on every vehicle you ever add.

Constraint

NTEP evaluates the instrument as a whole, including how it behaves under conditions you cannot control on a phone: signal loss, battery states, backgrounding, OS updates. The accuracy requirement is unforgiving and, unlike an internal quality bar, you do not get to argue about the methodology. Either the measurement holds or it does not.

Running alongside that was a second constraint with a different shape. The company was heading into investor due diligence, and the AWS account had grown for years without tagging discipline. Nobody could answer 'what does this cost and why' with confidence, which is a question that gets asked in every data room.

Decision

On certification, we rejected the hardware meter. The honest case for hardware was strong: it is a solved problem, the certificate already exists, and the engineering risk drops to nearly zero. We took the software path because the per-vehicle economics compound. Every car added after certification costs nothing extra in meter hardware, and a fleet operator evaluating platforms feels that immediately. The cost was a long certification effort with a real chance of failing, and a measurement discipline in the mobile code that no ordinary app needs — measurement error had to stay under 0.1%.

On the cloud account, we rejected cleaning up in place. Tagging retroactively, deleting suspicious resources and hoping nothing was load-bearing is how you take production down on a Thursday. We built a new AWS account with infrastructure-as-code and migrated onto it. That is strictly more work than a cleanup pass, and it produces something a cleanup never does: a bill where every line traces to a definition in a repository. In a data room that difference is the whole point.

On AI, the roadmap was sequenced by data readiness rather than by how interesting the item was. Dispatch agents were the headline. Demand prediction went first, because years of ride history already existed to train on, and routing improvements depended on knowing where demand would be.

What shipped

An NTEP-certified taxi meter app with measurement error under 0.1%. A full AWS inventory and cost audit, followed by migration to a new, fully described AWS account running at roughly $1,185 per month after cleanup. A platform rebuild aimed squarely at investor due diligence. And an AI roadmap covering demand prediction, driver routing, dispatch agents, AI QA for the mobile apps and fleet rebalancing.

Numbers

Measurement error under 0.1%, certified. AWS run-rate approximately $1,185 per month after the migration and cleanup. Six years as CTO, 2019 to 2025.

What I'd do differently

I would have tagged the AWS account from the first month. Every hour of the audit existed because nobody spent ten minutes a week on discipline for four years. It is the cheapest work in this entire case study and the only part that was pure catch-up.

On certification, I would have built the measurement test harness before writing the meter logic, not alongside it. We iterated on accuracy with a measuring setup that was itself still changing, which made a slow process slower.