One fractional CTO. Six months. A complete fleet-operations platform.

The client

RYD Nepal rents motorbikes to delivery riders in Kathmandu. A rider walks in, signs a contract, pays a deposit, and rides out the same day; RYD handles servicing, repairs, and paperwork while the rider earns on delivery platforms. The company also leases bikes in bulk to B2B partners. By late 2025 the fleet was approaching a hundred bikes — and the operation ran on spreadsheets, paper contracts, and the memory of whoever was at the desk.

The problem

Fleet rental looks simple and isn't. Every rider touches a dozen intertwined records: a contract, a deposit governed by policy, a bike assignment (often through a prebooking and a dispatch), a weekly bill with fines, discounts, and partial payments, attendance, accident claims, and sometimes a temporary replacement bike while theirs is in the workshop. Every bike has its own life: a kilometre-based service schedule, job cards, parts drawn from a stock ledger, GPS and odometer data syncing in from trackers.

At twenty bikes, spreadsheets survive this. Approaching a hundred, they don't: deposits get miscounted, services go overdue, and the weekly billing run takes a full day and still ships errors.

And no off-the-shelf tool fits Nepal. Staff think in the Bikram Sambat calendar (it is 2082 in the office, not 2026), the timezone is UTC+5:45, amounts are in NPR, and payroll follows Nepali tax slabs and SSF contributions. Localisation this deep isn't a settings toggle — it has to be designed in.

What we built

A single internal platform the whole company runs on:

• Riders & contracts — onboarding, contracts, deposit policies, terminations, temporary bike assignments
• Fleet — bike registry, GPS and odometer sync, picture library
• Dispatch & operations — prebookings, dispatches, rider attendance
• Finance — weekly billing with fines, discounts, and payments; deposit ledger; expenses with vendors, bank accounts, and petty cash
• Maintenance — service schedules by kilometre, mechanic job cards, parts stock ledger with automatic deduction
• Accidents — claim tracking from incident to settlement
• B2B — bulk bike assignments to partner companies at negotiated rates
• Payroll — Nepali tax slabs, SSF, advances, and allowances
• Workflow engine — templated multi-step processes (rider onboarding, dispatch, pre-delivery inspection) with approvals and auto-generated PDF documents
• Security — role-based access control, TOTP two-factor auth, domain-restricted login, and email-gated destructive actions

Stack: Next.js 16 · React 19 · TypeScript · PostgreSQL · Prisma · Tailwind + shadcn/ui · NextAuth with TOTP 2FA · S3 · Puppeteer for PDF generation

How we shipped it

Two tools, one loop.

v0 for the surface. Early on, v0 turned rough sketches into working shadcn/ui screens in minutes. More importantly, it forced a design system into place before the first real feature: one page shell, one table pattern, one form pattern. All 71 screens follow it — which is why the app feels like one product rather than six months of accretion.

Claude Code for everything else. The daily loop: describe the feature in domain language ("a mechanic opens a job card against a bike's due service, logs the parts used, and those parts come out of stock") → Claude Code drafts the schema change, the migration, the API routes, and the UI → the CTO reviews the migration and the business rules → ship. Repeat, 171 commits' worth.

Three practices made the AI output production-grade rather than demo-grade:

1. A conventions file the AI actually reads. A CLAUDE.md in the repo encodes the house rules — how dual-calendar dates are handled, how migrations must be created, access control as pure functions, the standard API shape. Every generated feature lands consistent, because the rules travel with the code.
2. Persistent memory across sessions. Claude Code maintains a domain map of the business between sessions — what a dispatch is versus a prebooking, which actions are email-gated — so a session in month five starts with context instead of archaeology.
3. Migration discipline, enforced. Eighty-five reviewed, committed migrations. The AI writes them; a human reads every one before it ships. The schema is where AI mistakes get expensive, so that's where the review time is concentrated.

Where AI actually moved the needle

An honest split.

AI was superb at consistent implementation at scale — the platform has 207 API endpoints, most of them careful variations on a shared pattern, which is exactly what a model produces faster and more uniformly than any team; well-specified gnarly logic (Bikram Sambat ↔ Gregorian conversion, UTC+5:45 date handling, Nepali payroll math); integration plumbing (PDF generation, S3 uploads, GPS sync, TOTP); and tireless refactoring and code review.

A human stayed essential for domain modelling (deciding that a dispatch and a prebooking are different things is a business decision, not a coding one), data-integrity review on every schema change, security posture, and saying no to features.

The result

The platform is in production and the RYD operations team runs the business on it daily. Weekly billing is generated, not assembled by hand. Every deposit, fine, and spare part sits on a ledger with an audit trail. New feature requests routinely go from conversation to production in days.

Conventionally, a system of this scope — an ERP-grade internal platform with payroll, billing, inventory, and a workflow engine — is a four-to-six-person team working for a year or more. RYD got it from one fractional CTO working alongside AI tooling, in under six months, at a small fraction of that cost.