A calibrated backlog
Epics, stories, hour estimates, sprint assignments, dependencies — plus a discovery-gaps report listing the always-required work (CI/CD, error monitoring, access control, i18n) that wireframes never show.
AI-assisted product development
We ship with AI. We publish the numbers.
NewEcom.AI is a product development studio that builds software with AI-assisted delivery — and quotes from measured actuals instead of optimism. Every sprint produces the same artifacts: a velocity record, a change-request ledger, and a client review deck. The five Factory skills we open-sourced are the system we run internally.
The problem
AI made building fast. It didn't make estimating honest.
An agent can write a CRUD screen in minutes, so the demo lands and the quote gets aggressive. Then the project meets the parts an agent doesn't shortcut: auth flows, payment webhooks, subscription billing, reconciliation, the composite index nobody scoped. The build is fast and the estimate is still wrong — and on a fixed bid, the estimate is the part that decides whether you made money.
We hit this ourselves. On a multi-tenant SaaS delivery, our billing epic was scoped at 14 hours and took 64. Instead of absorbing it quietly, we instrumented the delivery, measured where estimates broke, and turned the correction into the system we now run every project on.
How we work
Two phases, so the fixed price is based on evidence
Most studios quote a whole build up front from a wireframe and a feeling. We split the engagement, so the number that matters is priced against your project's real measured velocity — not an industry average.
-
Phase 1 — Discovery, built and measured
We turn your wireframes into a full backlog — epics, stories, hour estimates, sprint plan, and a discovery-gaps report naming the infrastructure work the wireframe doesn't show. Then we build it, and every story is tracked: hours, pull requests, test counts, carry-overs. You get working software and, just as importantly, a velocity dataset for your actual codebase.
-
Phase 2 — Fixed price, quoted from Phase 1 actuals
The remaining scope is priced against what your project actually delivered per sprint, with infrastructure stories corrected by the factor we measured rather than the one we hoped for. The risk premium a studio normally hides in a padded quote is replaced with data you can audit.
Scope changes go through a written process
A change request is classified, sized with the infrastructure correction applied, and run through an absorbability test against remaining sprint capacity. You get a recommendation — absorb, defer, or split — inside an agreed response window, plus a plain-language email you can act on. No work starts before written approval, and change-request hours are tagged separately so they never contaminate the velocity baseline your Phase 2 price is built from.
The numbers
Measured on a real delivery
A multi-tenant SaaS platform on Next.js and Firebase: a 146-story backlog across 30 epics, of which roughly 90 stories shipped in phase one across six sprint segments and about 235 hours. These are delivery actuals, not projections.
- 11–18 stories shipped per sprint averaging ~14
- 46–62 min median pull-request duration open to merged
- 2–3 stories per active day sustained across sprints
- ~100 test definitions per story speed without a quality trade
The estimate-versus-actual record behind these numbers is what the free Factory skills encode. We'll walk you through the raw delivery data on a call — including the sprints that went badly.
What you get
Every sprint ends with the same artifacts
A sprint review deck
A ten-slide review at every sprint close: KPIs, velocity, what shipped, the story table with pull requests and durations, quality metrics, carry-overs, and what's next.
A change-request ledger
Every scope change classified, sized, and dispositioned, with hours tagged as original-scope or change-scope so the Phase 2 estimate stays clean.
An accessible design system
Colour tokens and a type scale checked for WCAG 2.1 AA contrast, delivered as a spec your engineers — and your coding agents — build against.
Tested, reviewed code
TypeScript strict, roughly a hundred test definitions per story, CI running lint, type-check, and tests on every pull request, with error monitoring wired from Sprint 1.
A milestone gate per sprint
Each sprint closes against an explicit, checkable definition of done before the next begins — and a UAT window where you sign off on what shipped.
Quality, security & privacy
We audit the code we ship, and hand you the scorecard.
At every phase close we rate the codebase against published frameworks rather than our own opinion of it — ISO/IEC 25010 for product quality, DORA for delivery health, and a SonarQube-style static gate for reliability, security, maintainability, coverage, and duplication. The result is a written scorecard you can hand to an investor, an acquirer, or the next technical lead.
Quality engineering
Zero TypeScript errors and zero lint errors at every sprint close — not at the end, at every close. Numbered architecture conventions enforced in-repo so an agent can't drift from them. On the last phase-one delivery: 2,926 unit tests across 168 files, roughly 1.07× test density against source, and no critical or blocker bugs across ~106 story pull requests.
Security
Tenant-scoped data isolation and rule-enforced access from the first sprint, signed webhooks with per-tenant endpoints, and secrets kept out of the repo. Before anything touches live payments we run an OWASP Top 10 review, static analysis, a dependency vulnerability scan, and secret scanning — as a gate with a written pass criterion, not a best effort.
Privacy & accessibility
EU data residency by default, GDPR data-export and account-deletion endpoints shipped as scoped stories rather than retrofitted, and multi-tenant isolation verified by an explicit no-cross-tenant-leak test. Accessibility is held to a WCAG 2.1 AA baseline, with the design system's colour and type tokens contrast-checked before build.
Quality gates are numbers, agreed before the phase starts
Each phase closes against thresholds that can be checked against the live repository and signed off in writing as part of acceptance — so "done" is not a conversation. A representative phase gate:
- TypeScript / lint errors0
- Production incidents in phase0
- Branch coverage on services≥75%
- Critical end-to-end flows covered≥5
- Security audit checklistComplete
- Lighthouse, mobile and desktop≥80
- AccessibilityWCAG 2.1 AA
- GDPR export + delete endpointsIn place
We asterisk the metrics we haven't earned yet
The last scorecard rated delivery at DORA Elite on three of four metrics — and flagged every one of them with an asterisk, because the product had no live customers at the time. Zero production incidents from zero customers is not the same signal as zero incidents from a real customer base, and a scorecard that doesn't say so is marketing. Ours names which ratings are measured, which are projected pending a tool run, and which aren't earned yet.
What we got wrong
The failures are published too.
Any studio can show you a case study where everything worked. These are the three misses from our own delivery record that changed how we work — all three are documented in the open-source skills:
- We underestimated billing by 4.6×. Scoped at 14 hours, delivered in 64. Infrastructure work — auth, payments, billing, webhooks — does not size like feature work. Now it carries an explicit correction factor at the backlog stage, before anyone signs.
- Two epics were added post-contract with no change request. They went straight into the backlog, which quietly contaminated the velocity data the next phase estimate depended on. Now every scope change is logged and tagged before work starts.
- We tried to plan a whole build in one phase. Committing to a full scope before seeing real velocity produces overcommitment. The Phase 1 / Phase 2 split exists because the single-phase version didn't hold.
We publish these because the alternative — a studio that has never reported a miss — is not more trustworthy, just less measured.
Fit
Who this works for
We do best on greenfield SaaS and internal platforms where the scope is real but not yet built: multi-tenant apps, dashboards and reporting, billing and subscriptions, third-party integrations, and the auth and permissions layer underneath them. Typical engagements run a few sprints of discovery-and-build before a fixed-price second phase.
We're a poor fit for staff augmentation by the hour, for rescuing a large legacy codebase, or for work where the scope can't be written down yet. If that's the situation, say so on the call and we'll tell you honestly.
Book a discovery call
Thirty minutes. Bring a wireframe, a rough scope, or just the problem. You'll leave with our read on the infrastructure work hiding in it and a realistic shape for phase one — whether or not you work with us.