How a Small Team Ships Fast

The Question I Get Most

Every time I tell another founder we shipped this in four months with a team of three, the next question is some version of: how?

I owe other founders an honest answer to that, not the polished one. The honest answer has two phases — a build phase that looked one way, and an operating phase that looks another. They both rely on the same underlying practices, but the hours behind them are very different. This post is about both.

The Team Was Three

It was me, my husband Ed, and an intern. That's the whole core team that built KinTrades from late October 2025 through the April launch.

Ed showed up nights to test, to break things, to give feedback that only someone who hires trades workers every month could give — and he was honestly pissed about it many evenings, because Ed hates computers. That's not a joke; it's the reason he's a tradesman. The man whose co-founder pitch was essentially "I came to skilled trades because I never wanted to sit in front of a screen" spent his nights for five months sitting in front of a screen testing the screens. He did it anyway, because the work mattered. That's family, and that's a co-founder.

The intern carried real weight too — testing, build help, the kind of consistent presence that gives a small team continuity it otherwise wouldn't have.

I did the architecture, the PRD, most of the coding, and the partnership work. But "two-person team" undersells it. It was three of us plus the community that kept showing up.

The Build Phase: Late October Through April

The cadence didn't start with the first commit. It started the day after AfroTech — late October 2025 — with 20+ days of post-conference sprint on the PRD, scope, and validation interviews. Once that was done, December opened the coding phase, and the same nightly grind carried through to April.

From late October through April, I built KinTrades nightly while juggling a full-time job and a family. 8pm to 2am most weekdays. Some nights to 4am when I was in flow. Some nights I didn't sleep at all. Weekends too. That was the window I had — after the workday ended, after dinner, after the kids and the rest of the house went quiet — and I used all of it, because the platform had to go live by April for a real event with real employers and real workers.

I'm not romanticizing this. I don't recommend it as a default. Burning candles at both ends has a real cost — to health, to relationships, to judgment. But I owe other founders the truth about what shipping a production platform in this timeframe as a bootstrapped team of three, around a job and a family, actually looked like. It looked like that.

What kept it going wasn't discipline alone. Discipline gets you through a week. Five months of nights, with a day job and a family, runs on something else: passion for the people the platform was built to serve, and a community that kept showing up — workers, employers, students, partners, friends — to test, give feedback, and remind me what the platform was for on the nights I was too tired to remember.

1,000+ commits across the four coding months didn't happen on a tidy weekly schedule. It happened because every night from late October to April was either a build night or a recovery night, with very few in between — and because we had a real go-live deadline with real people counting on us being ready.

The Operating Phase: Working Toward Sustainable

Once the platform was live and the operational systems were in place, I made a deliberate change. The grind cadence ships things. It does not operate things sustainably. Operating a platform — responding to real users, making thoughtful product decisions, building partnerships, sustaining founder energy — requires a cadence you can hold for years.

I work full-time as a Principal Technical Program Manager. Every hour I spend on KinTrades is personal time — evenings and weekends, outside my workday. That's a permanent constraint, not a temporary one, and the cadence I'm working toward has to fit inside it.

Right now that cadence is roughly 22 hours a week: Monday through Thursday evenings (8–10pm), Friday is still an all-nighter, Saturday morning (8–11am) for build or program-management work, Sunday for a few hours of team meetings. That's where I'm steering it.

And it's the target, not a contract. As a mom, my schedule shifts around school shows, sports games, and homework help that can't wait. The hours and the cadence both move. What doesn't move is that the work stays outside my workday, and that the kids come before the codebase. Tighter than the build. Not sustainable yet. Built around being a mom, not around it.

The question that shapes the rest of this post: how do you keep momentum at a fraction of the hours that built the platform, while still working toward less — and while staying present for the family you're building this around?

The Project Board Is the Plan

This was true in the build phase. It's even more true now.

Every piece of work — code, content, ops, partnerships — has a ticket. No silent in-flight work. The board has categorized work streams (build, ops, content, partnerships, planning) that map to a weekly view, so I can see at a glance what's in scope and what's deferred.

Conventions matter more than tooling. The conventions we settled on:

• One ticket per outcome, with explicit acceptance criteria
• Category labels that roll up to a weekly summary
• A "now / next / later" structure inside each category
• Nothing is in progress without a ticket, no exceptions

When the board is the plan, the weekly meeting is short. We're not negotiating priorities — we're confirming the board reflects them. At ~22 hours a week, that short meeting matters more than it did when I had every night.

Weekly Cadence

Predictability beats ambition. The same hours every week compound. The heroic 30-hour weekend doesn't — it usually trades next week's energy for this week's progress and leaves the platform worse on Monday.

The current cadence:

• Sunday team meeting — alignment on the week's scope, what's deferred, what's blocked
• M–F 8–10pm — build window, focused on the highest-priority ticket on the board
• Mid-week ops check — short, fixed, non-negotiable; catches issues before they grow
• Saturday morning — review, content, planning, anything that needs daylight thinking instead of late-night focus

The constraint becomes a feature: when the time block is fixed, you stop debating whether to work and start choosing what to work on. The build phase had no such constraint, and the discipline that made the cadence work then is what makes ~22 hours a week work now.

AI-Assisted Development

This is the part of the story that's most specific to KinTech — and the part most founders ask about.

AI tooling integrated into the development loop changed the math of what a small team can ship. The shape of the change isn't "AI writes the code while we sleep." It's that the bottleneck shifted. For most of software history, the bottleneck for a small team was typing speed and context-switching cost. With AI in the loop, the bottleneck became review-and-decide capacity — how fast a human can read a proposed change, evaluate whether it fits, and approve or redirect it.

In the build phase, that leverage meant I could ship in a 5-hour nightly window what would otherwise have taken a long weekend. In the operating phase, it's what keeps ~22 hours a week productive instead of barely sustaining — and what gives me a path to reduce that further over time.

Four things made AI assistance work for us, not against us:

• Human review, always. Every AI-generated change goes through the same CI and the same human review as any other change. No autonomous merges. The AI proposes; the founder decides.
• Persistent context. The tooling remembers project decisions across sessions — naming conventions, architectural choices, the reasons certain things are the way they are. We don't re-explain the codebase every time.
• Sub-agents for parallel work. Research, test generation, refactoring, exploratory searches — these run in parallel rather than sequentially, which matters enormously when your build window is two hours.
• Pre-commit hooks as the safety net. Linting, type checks, and basic tests run on every commit. Catches problems before they reach CI. Makes the review-and-decide loop tight.

The result is a small team operating at multiples of its headcount, without the quality compromises that usually come with going fast.

Pre-Commit Hooks as the Quality Floor

Every commit runs linting, type checks, and a fast subset of tests before it lands. This adds seconds to each commit and saves hours of debugging downstream. It also means AI-generated code passes the same quality bar as everything else — there's no "AI code" tier with different standards.

When you only have ~22 hours a week of personal time to work with, the worst thing that can happen is spending three of those hours debugging a regression you could have caught at commit time. Hooks are how you don't do that. The same logic applied at 2am during the build — fewer middle-of-the-night problems compounding into morning chaos.

Why This Compounds

Each practice individually is incremental. Together they multiply:

• The project board removes the friction of figuring out what to work on
• The cadence removes the friction of deciding when to work
• AI assistance removes the friction of producing the first draft
• Pre-commit hooks remove the friction of catching problems late

Each removed friction is small. Together they're what made 4-hour nights productive enough to ship in four months — and what makes ~22 hours a week productive enough to keep building now.

The Takeaway

The interesting question isn't "how did you write so much code." It's "how did you keep it coherent — across two very different phases."

Project discipline + AI leverage + a tight commit loop is the answer to both. In the build phase, those practices let nightly grind produce coherent output instead of chaos. In the operating phase, they let ~22 hours a week sustain real momentum — and give me a path to keep reducing it.

For founders in the grind phase right now: it's real, it's normal, and it has a cost. Build the practices that will let you transition toward a sustainable cadence the moment you can. The same systems that protect quality during the grind are the ones that let you keep moving as you slow down.

For founders in the operating phase: the constraint is the design parameter. Build a system that fits the hours you actually have. The hours start producing differently when you do.