DEV Community: Info Inlet

Three Numbers as Engineering Constraints: $0, 14, 100%

Info Inlet — Fri, 22 May 2026 04:34:58 +0000

For about fifteen years, "MVP" has been the universal cover for shipping incomplete software. A login that breaks on mobile, three features that work and two that don't, "we'll harden it later" — all of it gets a free pass under the MVP framing.

We stopped accepting that framing on our team a while ago. But it took us a while to figure out why the MVP framing was so sticky in the first place, and what to replace it with.

The answer turned out to be three numbers. Treated not as marketing claims, but as engineering constraints that force specific architectural decisions.

This post is about those three numbers, and what they actually force in code.

The Three Numbers

$0 — the invoice for the first project we do with any client
14 — the number of days from kickoff to a shipped, production-ready product
100% — the percentage of source code that transfers to the client's GitHub org on Day 14

Each one is unusual. Together, they force five engineering decisions that most teams don't make.

Constraint 1: `$0` Forces You to Delete the Sales Pipeline

If the first project is free, you cannot afford a traditional sales pipeline. Most agencies spend 25-40% of their revenue on pre-sales work — proposals, RFP responses, discovery sprints, alignment meetings. That cost center has to go.

In practice, this means the sales process gets replaced with code.

// scope/intake.ts
export const ProjectScope = z.object({
  auth: z.object({
    providers: z.array(z.enum(['email', 'google', 'github', 'apple'])),
    mfa: z.boolean(),
    passwordReset: z.literal(true), // always included
  }),
  payments: z.object({
    provider: z.enum(['stripe', 'paypal', 'none']),
    recurring: z.boolean(),
  }),
  dashboards: z.array(
    z.object({
      name: z.string(),
      widgets: z.array(z.enum(['table', 'chart', 'kpi'])),
    }),
  ),
});
export type ProjectScopeT = z.infer<typeof ProjectScope>;

The intake form is a typed schema. Scaffolds, demo seeds, and test suites all consume the same type. What used to be a 90-minute discovery call is now a 15-minute conversation plus a typed object.

The $0 is not generous. It is the result of deleting 25-40% of overhead that did not produce code.

Constraint 2: `14` Forces You to Finalize the Schema on Day 0

If you have 14 days, you cannot afford a single multi-table schema migration mid-build. A migration on Day 9 propagates into the frontend, breaks half-finished forms, and blows the timeline.

This forces the rule: the database schema is finalized on Day 0, before any feature code is written.

// schema/index.ts — completed on Day 0
import { pgTable, uuid, text, timestamp, pgEnum } from 'drizzle-orm/pg-core';

export const roleEnum = pgEnum('role', ['admin', 'member', 'viewer']);
export const planEnum = pgEnum('plan', ['free', 'pro', 'enterprise']);

export const organizations = pgTable('organizations', {
  id: uuid('id').primaryKey().defaultRandom(),
  name: text('name').notNull(),
  plan: planEnum('plan').notNull().default('free'),
  createdAt: timestamp('created_at').notNull().defaultNow(),
});

export const users = pgTable('users', {
  id: uuid('id').primaryKey().defaultRandom(),
  organizationId: uuid('organization_id')
    .notNull()
    .references(() => organizations.id, { onDelete: 'cascade' }),
  email: text('email').notNull().unique(),
  role: roleEnum('role').notNull().default('member'),
  createdAt: timestamp('created_at').notNull().defaultNow(),
});

The schema is reviewed, locked, and merged on Day 0. Feature code begins on Day 1 with the data model already correct.

Most teams resist this because it feels like "designing too much up front." But the alternative — incremental schema discovery across two weeks — costs 5-10x more in rework. The 14-day constraint forces the disciplined version.

Constraint 3: `14` Also Forces You to Make CI Reject Sloppy Work Automatically

14 days does not leave time for "let's discuss this PR in standup." A senior engineer's review time has to be spent on architecture, not on catching missing tests or any types.

The fix: CI rejects everything mechanical, before it ever hits a human reviewer.

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
      - uses: actions/setup-node@v4
        with: { node-version: '20', cache: 'pnpm' }
      - run: pnpm install --frozen-lockfile
      - run: pnpm tsc --noEmit                                 # 1. types strict
      - run: pnpm lint --max-warnings=0                        # 2. no warnings
      - run: pnpm test --coverage --coverage.threshold.global=80
      - run: pnpm audit --audit-level=moderate                 # 3. deps clean
      - run: pnpm playwright test --reporter=line              # 4. e2e
      - run: pnpm build                                        # 5. build green

If any of the six steps go red, the PR cannot merge. Human review then becomes "is this the right architecture" instead of "did you forget to add a test." That's the only way 14 days works.

Constraint 4: `100%` Source Code Transfer Forces You to Use Vanilla Stacks

If you have to transfer 100% of the source code to the client on Day 14 — actual repo, actual commit history, actual CI config — you cannot ship code that depends on a proprietary in-house framework. The moment you do, "transferred" becomes a lie.

This forces a specific stack selection rule: vanilla over proprietary, always.

Category	✅ Pick	❌ Avoid
Framework	Next.js / Remix / Hono	In-house framework
ORM	Drizzle / Prisma	In-house ORM
Auth	Better Auth / Lucia / NextAuth	In-house auth SDK
Deploy	Vercel / Fly / Railway	In-house deploy platform
UI	shadcn/ui + Tailwind	Closed-source component library

A client should be able to fire us on Day 15 and hand the repo to any senior engineer in the world. That's what 100% actually means.

Constraint 5: "Not an MVP" Forces You to Burn Day 12 on QA, Not Features

If "the real product" is the promise, then somewhere in the 14 days, feature work has to stop and quality work has to take over. We made that day explicit: Day 12 is QA-only. No new features land on Day 12 — only edge-case fixes.

Day 12 — QA checklist (abridged)
[ ] Mobile: 360 / 768 / 1024 / 1440 px, every screen
[ ] Forms: empty / max-length / invalid input boundaries
[ ] Auth: token expiry redirect, refresh flow, session invalidation
[ ] Payments: card decline, 3DS, webhook double-send idempotency
[ ] Error states: 404, 500, offline, slow network
[ ] Performance: Lighthouse ≥ 90, TTI < 2.5s
[ ] A11y: axe violations = 0
[ ] Security: OWASP Top 10 quick pass

Without a dedicated QA day, "real product" silently degrades into "demo-quality MVP." Day 12 is the forcing function.

The Pattern

Each of the three numbers, on its own, looks like a marketing claim. But each one is actually a forcing function that requires a specific engineering decision:

Number	Forcing function
`$0`	Replace sales pipeline with typed scope code
`14`	Finalize schema on Day 0; CI rejects mechanical issues
`100%`	Vanilla stack only; no in-house framework dependencies
(Not an MVP)	Day 12 = QA-only, no new features

Companies that treat these as marketing claims fail at them. Companies that treat them as engineering constraints can actually deliver.

Where We Apply This

We're the team behind Fluxez — a project where the entire engineering organization is built around these three numbers as constraints. The first project a founder does with us is $0, ships in 14 days, and transfers 100% to their GitHub on Day 14.

If you want to see real templates, our scaffold patterns, or the schema-on-Day-0 examples that make this possible, the relevant pieces are on fluxez.com.

We Built a Company That Ships Your Complete Software Product in 14 Days — Free First. Yes, Really.

Info Inlet — Thu, 21 May 2026 09:05:35 +0000

We Built a Company That Ships Your Complete Software Product in 14 Days — Free First. Yes, Really.

There are three sentences I say to founders almost every week that almost no one believes the first time:

We don't build MVPs. We build the complete product.
We ship it in 14 days.
The first project is free.

The first reaction is always the same. A pause. A polite smile. The unspoken assumption that there must be a catch.

There isn't one. Taken together, these three sentences describe the most genuinely revolutionary shift in how software gets built since the move to cloud — and almost no one is talking about it yet.

This post is for the developers, technical founders, and engineering leaders who keep asking me "how is that possible?" Here's the honest answer, claim by claim.

"We Don't Build MVPs. We Build the Complete Product."

The minimum viable product. The most-quoted phrase in startup land. For fifteen years, every founder heard the same advice: ship the smallest possible version, learn fast, iterate.

It was good advice in 2010. It became terrible advice somewhere around 2022.

Here is what an MVP actually looks like in 2026:

A login page that breaks on mobile
Three features that work, two that don't
No payments — that was "phase 2"
A database that wasn't designed for scale
No tests
A founder telling investors "we'll harden it later"

This is what most founders ship. Then they wonder why their conversion rate is 0.4%, why customers don't trust them, why churn is 80%.

It is not a product problem. It is not a market problem.

It is that users no longer grade you on a curve. They have used Stripe and Notion and Linear. They compare your product to the best one they have ever touched. Ship half a product in 2026 and they leave in 30 seconds.

The MVP framework was a coping mechanism for an era when shipping software was slow. That era is over.

So we don't ship MVPs. We ship the complete product — authentication, payments, dashboards, mobile-responsive, tested, deployed, documented. The actual thing you would be proud to put on Product Hunt. Not a demo. Not a v0.1. The product.

This is the first claim, and it is non-negotiable.

"We Ship It in 14 Days."

This is the part developers find hardest to believe.

For twenty years, "real software" meant three to six months minimum. Discovery sprints. Design sprints. Multiple dev cycles. QA. Most agencies still operate on that timeline.

We do not. And it is not because we cut corners or hire offshore for cheap.

It is because the economics of software actually changed. Senior engineers paired with the right AI tools ship roughly four to six times faster than they did three years ago, with equal or higher quality. We restructured the entire company around that reality. Every day in the build has a clear deliverable. No discovery sprints. No alignment weeks. No buffer days.

The structure is the discipline.

Other companies have not caught up yet because they are still organized around 2019's economics. Their billing models, their staffing models, their pricing — all of it assumes software takes six months. They cannot drop to fourteen days without dismantling themselves.

We were built around fourteen days from day one. Day 0 is a written scope. Day 1-3 is foundation. Day 4-11 is build and polish. Day 12 is QA. Day 13 is deploy and documentation. Day 14 is handover. No slack in the schedule — and no slack needed, because the team is small, senior, and AI-augmented.

This is the second claim, and it works because the company was designed around it from the start.

"The First Project Is Free."

This is the one that sounds like a scam.

No credit card. No subscription. No contract. You describe your idea. We build the complete, production-ready product. You keep the source code in your own GitHub repository. If you never work with us again, you walk away with everything we built. Nothing comes off your card. Ever.

Why would anyone do that?

Because we are not a "close the deal in the first meeting" company. We are building a long relationship with the founder, not a transaction. The only way to start a real relationship is to prove something, not promise it.

Most agencies pitch you for three weeks, then send a $50,000 contract. Most SaaS tools offer a 14-day trial with a card on file. Most AI builders promise the world and ship a broken demo.

We do the opposite. We just build the thing. Then you decide.

If the work is good, you come back. Most founders need a second product, a refactor, a new feature, a different vertical, a B2B version of the B2C app, a mobile app to pair with the web one. The work compounds naturally. We don't need a contract to lock you in — we need to actually be good.

If the work is bad, you walk away with the product, no money lost. Either way, the founder wins.

The free first project is not a discount. It is not a loss leader. It is the company.

This is the third claim, and it is the one that puts our money where our mouth is.

Why These Three Together Are Revolutionary

A free MVP would be a gimmick — half-finished software given away to lock you into a paid tier. You have seen that move a thousand times.

But a free, complete, production-ready product, shipped in 14 days, with full source-code ownership and no contract — that is a fundamentally new thing in the software industry. As far as we know, we are the only company in the world doing this combination.

It changes the founder's calculation completely.

You used to ask:

"Can I afford to gamble $50,000 on an agency I have never worked with?"

Now you get to ask:

"Do I actually have an idea I want to ship?"

That second question is the right question. That is the question every founder should be asking. Money, time, contracts, vendor lock-in — we removed all of it on purpose.

If you have an idea, you should be shipping it. Everything else is friction we deleted.

What This Doesn't Mean (The Honest Part)

We are upfront about a few things, because we want every founder to have a clear picture before they start:

"Free" means the build itself is free. Source code in your GitHub. Live preview running on our infrastructure during the demo window. Full IP transfer. Hosting on your own cloud, deployment pipelines to your cloud, mobile App Store or Play Store submission, and ongoing maintenance past Day 14 are paid add-ons. We tell you this in the first conversation, not after.
"14 days" means we build the scope you sign off on at Day 0. We do not promise "whatever you want in 14 days." We promise the scope, in 14 days.
"Complete product" means production-ready — the kind of thing you can put in front of real users without being embarrassed. It does not mean "feature-complete forever." The next thing is the next project.

These caveats are part of the deal, and they are written down before any code gets written. No surprises on Day 14.

Why I'm Writing This

Founders have been pitched a thousand promises by a thousand agencies over the years. Most of those promises turned out to be incomplete, expensive, or both.

So when we say "free, 14 days, complete product, no MVP, revolutionary," I understand the instinct is suspicion. I would be suspicious too.

The only response I have is to make the offer real enough that you can test it without risk. No card, no contract, no catch. You bring an idea. We build the product. You keep the code.

If we are right about this, founders will keep coming back, and we will build a company that lasts a long time. If we are wrong, we lose money on a few projects and learn something.

We are okay with that bet. The economics of software changed. Someone has to be the company that operates as if that change is real.

That is us.

→ fluxez.com

How We Ship Production-Ready Software in 14 Days (Not MVPs)

Info Inlet — Wed, 20 May 2026 09:40:45 +0000

For about fifteen years, the software world has used "MVP" as an acceptable excuse for shipping broken things.

A login page that doesn't work on mobile. A payment flow that fails on the third edge case. A dashboard with no error handling. "It's an MVP" became the universal cover for incomplete engineering.

At our company, we stopped accepting that framing. Here's what we replaced it with — and the actual engineering workflow that makes it possible.

The MVP Was a Compromise With Slow Tooling

The original MVP idea made sense in 2010. Shipping was slow. Building anything took months. So you shipped the smallest possible thing, learned from real users, iterated.

But "minimum" became a permission slip. Teams started shipping things that weren't viable in any reasonable sense — they just barely compiled.

By 2026, the tooling has caught up. Senior engineers paired with the right AI tools can now produce in two weeks what used to take six months. The compromise that made MVPs necessary no longer exists.

So we stopped shipping them.

What "Finished Product" Actually Means in Our Workflow

When a founder describes an idea to us, we don't ask "what's the smallest version?" We ask "what does the production version look like?" Then we build that.

For us, "production-ready" is a defined checklist. It must have:

Authentication that works on every supported device
Payment integration tested against real Stripe events (or whatever the chosen processor is)
Mobile-responsive layouts at every breakpoint
Error states for every API call, not just the happy path
Database schema designed for the next 6 months, not the demo
A test suite that covers the critical paths
A deployment pipeline that doesn't depend on one person's laptop
Documentation that another engineer can read and contribute against

If a feature ships without those, it isn't production-ready. We don't call it "v1" or "MVP." We treat it as incomplete and finish it.

The Engineering Workflow

Here's the actual loop we run, condensed:

Day 1-2 — Scope lock

A senior engineer sits with the founder. The output is a written scope document, signed off by both sides. Anything not in this scope doesn't get built in this cycle. This is the single biggest predictor of whether the 14-day timeline holds.

Day 3-4 — Architecture + skeleton

Database schema, route map, third-party integrations decided. The skeleton of the codebase exists — empty endpoints, empty components, but the shape is there. AI tools accelerate this phase heavily because the structure is well-understood.

Day 5-10 — Build

This is where AI + senior engineer pairing pays off most. The engineer makes architectural decisions, names things well, reviews edge cases, and writes the tricky parts. The AI fills in boilerplate, generates the obvious stuff, and handles repetitive scaffolding. The engineer reviews every commit.

The ratio matters: AI doing 100% of the work produces fragile code. AI doing 0% of the work means we ship in 6 months. The right ratio — variable per task, but roughly 60/40 engineer-driving / AI-assisting — is where the speed comes from.

Day 11-12 — Hardening

Edge cases, error handling, mobile testing, accessibility check, security pass. This is where MVPs cut corners and we don't.

Day 13 — Staging + founder review

Everything deployed to staging. Founder gets a real walkthrough on real devices. Bugs filed.

Day 14 — Ship

Production deployment. Source code transfer to the founder's GitHub. Documentation handed over.

That's the loop. Nothing exotic — just a disciplined refusal to ship things that aren't finished.

What AI Actually Does (And Doesn't Do)

The "AI replaces engineers" framing is wrong. AI does not:

Make architectural decisions
Review its own security
Understand the business
Catch the edge case that only matters because of how this specific customer uses the product
Decide what to not build

What AI does well in this workflow:

Generate boilerplate (forms, CRUD, schema mapping)
Translate well-defined intent into code quickly
Handle obvious refactors
Write the first draft of tests
Catch syntax errors and obvious bugs

The engineer's job becomes increasingly about judgment — what to build, in what order, what to refuse, what to harden, what is the obvious-but-wrong shortcut. The typing is faster. The thinking is the same.

Why This Works Economically

If our team can ship a production-ready product in 14 days instead of 6 months, the unit economics change completely.

That's why our company can do something unusual: the first project we build with any founder is free. Not a stripped-down trial, not a "lite" version — the same full, production-ready product I described above, with the source code transferred to them at the end.

We can do this because the cost per project has collapsed. We do it because we'd rather show a founder our work than promise it. If they come back for a second project, the relationship is real. If they don't, they walk away with a product they own.

That's it. That's the company.

What This Means If You're Considering Shipping Something

If you've been sitting on an idea because every option in front of you came with a contract, a credit card, a six-month wait, or a $50K invoice — the economics of software have changed enough that those options aren't your only ones.

A team that ships finished products in 14 days exists. The first one can be free. The source code can be 100% yours.

If you want to see what that looks like for your idea, we're at
fluxez.com.