At Fluxez, every founder's first project costs $0, ships in 14 days, and 100% of the source code transfers to their GitHub on Day 14. The full production product — auth, payments, dashboards, mobile UI, tests, deploy — not an MVP.
This is an engineering post, not a marketing post. I want to walk through the five specific engineering decisions that make a $0 / 14-day / full-source-transfer model technically possible. None of them are obvious. All of them are non-negotiable. Remove any one and the model breaks.
The constraint stack
Three top-level constraints govern every line of code we ship:
| Constraint | What it forces |
|---|---|
| $0 | Zero billable hours can be spent on sales, scoping, or pre-sales. |
| 14 days | Zero hours can be spent on anything that isn't direct value delivery. |
| 100% source transfer | Zero proprietary code can ship inside the deliverable. |
These three constraints look like business decisions on paper. In practice, they cascade down into very specific engineering decisions — five of them, in our experience.
Decision 1: Day 0 schema lock — forced by 14
In a traditional agency, the data model evolves through the project. Sprint 1 ships a schema, sprint 3 refactors it, sprint 5 backfills production data. That works on a 6-month timeline. It does not work on 14 days.
So we lock the schema on Day 0, before any code is written.
sql
-- Day 0 deliverable: complete schema + migration files
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email CITEXT UNIQUE NOT NULL,
hashed_password TEXT NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE TABLE workspaces (...);
CREATE TABLE memberships (...);
CREATE TABLE billing_accounts (...);
-- etc, all in one pass
Why Day 0? Because every downstream decision — API contracts, ORM models, type generation, seed data, integration tests — depends on the schema. If the schema moves on Day 7, the cascade of rework eats two days minimum. On a 14-day budget, that's 14% of the project gone.
The forcing function isn't discipline. It's the calendar.
---
Decision 2: AI does mechanical work, humans do judgment work — forced by 14 Senior engineers + modern AI tooling ship roughly 4-6x faster than three years ago. We've measured it across ~100 projects internally. The speedup is real, but it is not evenly distributed.
The mechanical work gets faster:
- Boilerplate
- Type definitions
- Scaffolding (controllers, routes, services)
- CRUD handlers
- Basic unit test coverage
- Migration files
- Seed data
The judgment work gets exactly as fast as it ever was:
- Schema design
- Auth model
- Permission boundaries
- Security review
- Failure mode design
- Performance edge cases
So we built our delivery model around that split. AI generates the mechanical work, a senior engineer reviews it, accepts it, and spends their human time on the judgment work that actually moves the project.
This is a stack-level decision — not a tool choice:
Day 1-2: Schema, auth model, security review (senior eng, no AI)
Day 3-7: Scaffolding, CRUD, types (AI-generated, eng-reviewed)
Day 8-10: Business logic, edge cases (senior eng, AI-assisted)
Day 11: Performance + security pass (senior eng, no AI)
Day 12: QA freeze, no new features
Day 13-14: Polish + ship
If you flip the split — humans do the boring work, AI does the judgment work — the model collapses on Day 4.
---
Decision 3: Vanilla stack only — forced by 100% source transfer
If 100% of the code goes to the founder's GitHub on Day 14, we cannot ship anything that depends on a proprietary in-house framework. The moment we do, "transferred" becomes a lie. The founder would walk away with a codebase that only we can maintain.
So the stack is intentionally boring:
Backend: Node.js / TypeScript (Express or Fastify)
Database: PostgreSQL + Drizzle ORM
Frontend: Next.js + Tailwind + shadcn/ui
Auth: Lucia / NextAuth / Clerk (founder's pick)
Payments: Stripe
Hosting: Vercel / Railway / Fly.io (founder owns the account)
CI: GitHub Actions (committed in-repo)
IaC: Terraform or docker-compose (committed in-repo)
Notice what's not on that list: no internal CMS, no proprietary admin generator, no in-house ORM wrapper, no "Fluxez SDK." Any senior engineer on Earth can clone the repo on Day 15 and continue maintenance immediately. That's the entire point of the 100% transfer.
This sounds restrictive. It is. It's also liberating — because every engineer on our team can move between projects without a learning curve.
---
Decision 4: Typed scope at intake — forced by $0
$0 means we burn money on every project we don't earn back through future work. The model only stays alive if scope is typed precisely at intake, before Day 1.
We use a literal TypeScript file:
// project_intake.ts
type ProjectScope = {
product: 'B2B SaaS' | 'B2C App' | 'Internal Tool' | 'Marketplace';
auth: 'email_password' | 'magic_link' | 'oauth';
payments: 'stripe_subscriptions' | 'stripe_one_time' | 'none';
data_complexity: 'simple_crud' | 'multi_tenant' | 'event_sourcing';
ui_surfaces: ('web' | 'mobile_web' | 'admin_dashboard')[];
integrations: ExternalIntegration[]; // max 3
out_of_scope: string[]; // explicitly written, signed
};
type ExternalIntegration =
| 'stripe'
| 'sendgrid'
| 'twilio'
| 'segment'
| 's3'
// closed enum — no "other" option
The closed enum is intentional. "Could you add custom OCR pipeline integration with our existing vendor's API?" is not a scope option. The intake process either reshapes the request into one of the typed options or politely declines the project.
This is not bureaucracy. It is the only way $0 survives at scale. A traditional agency absorbs scope creep through change orders. We can't. So we eliminate the possibility at the type level.
---
Decision 5: Day 12 = QA-only freeze — forced by 14
The last engineering decision is the cheapest to describe and the hardest to enforce: no new features after Day 12.
Day 12 09:00 — Feature freeze. PRs that add new code paths are rejected.
Day 12-13 — QA, edge case testing, security pass, performance check.
Day 13 18:00 — Code freeze. Only critical bug fixes after this point.
Day 14 09:00 — Deploy to production. Handoff begins.
Without this freeze, every project ends with a panicked Day 14 morning where the deploy breaks because someone added "one last feature" at 11 PM the night before. We've watched this exact failure mode kill agency projects we used to work at. So we built the freeze into the calendar.
This sounds obvious. It is not. Most agencies don't do this because their billing model rewards last-minute additions. Ours doesn't — there is no billing.
---
How the constraints reinforce each other
The interesting thing is that each constraint reinforces the others.
- $0 makes us delete the sales team → frees budget for engineering → makes 14 days realistic.
- 14 days forces schema lock + AI-assisted mechanical work → keeps engineering hours low → makes $0 survivable.
- 100% transfer forces vanilla stack → makes any engineer hireable on Day 15 → de-risks the bet for the founder.
Remove any one of the three and the other two collapse.
$0 + 14d, no transfer → founder is locked in → trust dies → model dies
$0 + 100% transfer, no 14d → no urgency → engineering hours balloon → $0 dies
14d + 100% transfer, no $0 → sales pipeline returns → 25-40% revenue bleeds out
That's why I describe this as the first software company built around the combination, not the first one to offer any single piece of it. Individually, each of these is achievable. Together, they require the whole company to be reorganized around them.
---
What this means for you, even if you don't use Fluxez
I'm not writing this as a pitch. I'm writing it because I think these five decisions are useful patterns for any engineering org operating in 2026:
1. Lock the schema before you write code. Every refactor downstream is a tax.
2. Split mechanical work from judgment work. AI does the first half. Humans do the second. Never the reverse.
3. Ship a vanilla stack you can hand off. Proprietary infra is technical debt the founder will pay later.
4. Type your scope. If "other" is an option in your intake form, you're going to lose money on scope creep.
5. Enforce a hard freeze 48 hours before ship. Every "one last feature" is a Day-14 incident waiting to happen.
You don't have to run a $0 model to benefit from any of these.
---
The offer (for founders reading this)
If you happen to be a founder reading this — your first project at Fluxez is genuinely free. 14 days. Full production product (not an MVP). 100% of the source code in your GitHub. Project #2 onward is paid at standard rates we tell you before Project #1 starts. No card, no contract, no surprise.
→ fluxez.com
If you're an engineer who finds the constraint stack interesting and wants to dig into specific implementation details — drop a comment below. I'll answer every comment for the next 72 hours.
What's the engineering decision in your current org that's the closest equivalent to one of these five?
Top comments (0)