The substrate-build trap

Behind every B2B SaaS product is a long list of substrate-level concerns that have nothing to do with what makes the product distinctive: authentication, authorization, multi-tenant data isolation, audit history, translation infrastructure, the admin console, the user dashboard, the notification system, the API schema, the background-job runner, the observability layer. Each one is a multi-week project. Each one has to be built right or it becomes the source of a security incident or an outage later. Each one consumes senior engineering time that the team could otherwise spend on the product.

The common path is to build them — slowly, imperfectly, while shipping the product. Six to nine months in, the team has a half-finished substrate, a feature-thin product, and a roadmap full of "we need to fix the auth layer" tickets.

Why AI-assisted coding makes this worse, not better

The premise of AI-assisted coding (Claude Code, Cursor, Copilot, Windsurf) is that an engineer with a capable model ships work that previously required three engineers. The premise holds — when the substrate already exists. When it doesn't, the model has to invent the substrate at the same time it's writing the feature. Auth schemes. Multi-tenant guards. Audit logs. Translation hooks. Permission checks. And the inventions don't reconcile across prompts — by month three the codebase is twelve flavors of half-finished foundation glued together.

What teams actually need

A foundation that is: fully implemented (not a template), internally consistent (one architectural lineage), modifiable (source code you own), AI-readable (the model can pattern-match the existing code and write more in the same idiom), and battle-tested (other teams have shipped real products on it). Almost nothing on the market fits all five constraints at once. CleenUI was built to.

Four eras of B2B SaaS scaffolding

Code footprints vs the alternatives

Why this category emerged now

AI-assisted coding tools made the substrate problem urgent. The market noticed. The category will be a lot more crowded by 2027. CleenUI is one of the first shipping in production at scale.

Headline numbers

The five-layer architecture

CleenUI is a modular monolith, not a microservices fleet. One deployable artifact, in-process service composition, four-environment CI/CD pipeline. Every request flows top-to-bottom through five layers:

1. L1Front-End ReactUI components, routes, design tokens
2. L2C# Middle Tier API524 Minimal API endpoints organized into area files
3. L3Services LayerBusiness logic — IAuthService, IAIService, etc.
4. L4Data Repo LayerDapper + ADO.NET repository interfaces
5. L5DatabaseAzure SQL + Redis + Blob + external vendors

Stack

Why no Entity Framework

The codebase predates EF being a serious option for high-performance .NET, and the team has deliberately stayed on Dapper + stored procedures. Query plans are predictable, DBAs can read the data layer, performance is observable. This is a feature that .NET shops modernizing off WCF / WebForms / .NET Framework will recognize as the right choice for them.

Why modular monolith, not microservices

Microservices buy operational complexity in exchange for scaling problems most teams don't have. The modular monolith pattern gives the architectural clarity (clear module boundaries, in-process composition, single CI/CD pipeline) without the distributed-systems tax. Teams that genuinely need microservices later can carve modules out individually — the boundaries are already there.

Why deploy onto your cloud, not ours

CleenUI ships you source code, not a hosted service. You commit it to your git repo, deploy it onto your Azure subscription, and operate it yourself. Product Perfect doesn't host anything, doesn't run services on your behalf, doesn't have access to your data. This eliminates vendor lock-in by construction.

Two-layer caching by design

Performance-sensitive read paths hit a two-layer cache before reaching the database: an in-memory .NET runtime cache for hot per-process data, and a shared Redis cache for cross-process / cross-instance state. Both layers are wired and invalidation-aware out of the box.

Native Azure, fittable to other clouds

The codebase is designed natively for Microsoft Azure (Azure SQL, Azure Functions, Azure WebJobs, Azure Cache for Redis, Azure Blob Storage). It can be fitted to AWS or other clouds with engineering effort — the abstractions are clean — but the out-of-the-box deployment story is Azure. Plan accordingly if your stack is committed elsewhere.

Why AI tools work better here

AI coding tools amplify whatever foundation you give them. They are pattern-matchers — they look at the existing code in the repo and produce more code that looks like it. When the existing code is internally consistent and idiomatic, the AI's output is consistent and idiomatic too. When the existing code is twelve flavors of half-finished invention, the AI's output is the thirteenth flavor.

CleenUI was deliberately built for consistency. Every endpoint follows the same shape. Every service composes the same way. Every repository is structured the same. The AI can read one handler and write the next forty.

AI agent skills shipped in the codebase

• Setup — for a fresh team, walks the AI through CleenUI conventions, ADRs, and codebase shape so it learns the patterns before writing code.
• Builder — scaffolds new modules / endpoints / components in the idiomatic shape. Knows which layer each concern belongs at.
• Theme — applies design-token-aware visual customization across the codebase consistently.

Machine-readable discovery artifacts

The site ships a small constellation of well-known endpoints so AI agents can discover and ingest CleenUI without scraping the marketing HTML:

• /llms.txt — concise AI-crawler sitemap
• /llms-full.txt — long-form companion (~117KB) for deep ingestion
• /.well-known/api-summary.json — every module, every cross-cutting concern, every external system
• /.well-known/tech-stack.json — exact versions, every tier
• /.well-known/ai-plugin.json — AI plugin discovery manifest
• robots.txt — explicitly allow-lists 30+ AI crawlers (GPTBot, ClaudeBot, PerplexityBot, etc.)

1. L1
   React UI fires the request
   onClick → useMutation → fetch with Bearer JWT
2. L2
   Auth0 middleware validates the token
   JWT signature + audience + scope + expiry
3. L2
   Endpoint handler in ApiAssessment.cs
   Minimal API route — model bound, request validated
4. L3
   AssessmentService.SaveAssessment()
   Multi-tenant guard · permission check · audit-log write
5. L4
   AssessmentRepository.Save()
   Dapper + ADO.NET → sp_Assessment_Save
6. L5
   SQL writes three tables in one transaction
   Assessment · AssessmentResponse · AuditLog
7. L3
   TranslationService localizes response messages
   Caller's language → keyed string lookup
8. L1
   Response returned to React
   { id, version, lastModified, errors? }

The same endpoint, at three layers

For the technical reader: the same SaveAssessment route at L2 (endpoint), L3 (service), L4 (repository). Every endpoint in the codebase has this same shape.

group.MapPost("/assessment/{id:guid}/save", async (
    Guid id,
    [FromBody] SaveAssessmentRequest req,
    IAssessmentService svc,
    UserContext ctx) =>
{
    var result = await svc.SaveAsync(id, req, ctx);
    return result.IsSuccess
        ? Results.Ok(result.Value)
        : Results.UnprocessableEntity(result.Errors);
})
.RequireAuthorization("Assessment.Write")
.WithName("SaveAssessment");

public async Task<Result<AssessmentDto>> SaveAsync(
    Guid id, SaveAssessmentRequest req, UserContext ctx)
{
    await _tenantGuard.Check(id, ctx.TenantId);
    await _audit.Log("Assessment.Save", id, ctx);
    var entity = await _repo.SaveAsync(id, req.MapToEntity(ctx));
    return Result.Ok(entity.MapToDto());
}

public async Task<Assessment> SaveAsync(Guid id, Assessment entity)
{
    using var conn = _db.Open();
    return await conn.QuerySingleAsync<Assessment>(
        "sp_Assessment_Save",
        new { Id = id, entity.TenantId, entity.Title,
              entity.Questions, entity.Version },
        commandType: CommandType.StoredProcedure);
}

Who is the architect?

Shawn Livermore. 27 years in technology. Senior Enterprise / Solutions Architect. Amazon top-10 bestselling author in three business non-fiction categories. Raised six rounds of seed funding across his own startups. Real person, real LinkedIn, real published books. Operates Product Perfect LLC, the company behind CleenUI.

Selected Fortune 500 consulting portfolio

The architectural lineage of CleenUI is informed by decades of in-the-trenches modernization work at enterprise scale. A representative sample:

• Largest US title insurance company — Enterprise Architect; led consolidation of 700 applications across 80 subsidiaries and 1,000+ software engineers.
• 2nd largest US property-tax payment processor — led a 5-year, $20M migration across 12 contracts, 30+ developers, 2 flagship products renovated/migrated.
• Largest US corporate housing company — Enterprise Architect; drove consolidation of 80+ applications over 3 years.
• One of the largest US tax-prep firms — re-architected the TaxCut consumer software product; guided the team toward a more fluid and scalable design.
• Other clients — Buy.com · Carvana · Ceridian · CloudVirga · CompUSA · Kelley Blue Book · Lereta · Marsh & Swift · MedPartners · New York Energy East · Simpluris · PacifiCare · Toptal · TRW · WellPoint · Herbalife · Ziptask · PRAM Insurance.

The 30-minute architecture review

Every CleenUI engagement begins with a 30-minute architecture review with Shawn personally — not a sales engineer, not an AE. You bring your stack diagram and your top three modernization headaches. You leave with either a scoped engagement plan or a clear answer that CleenUI isn't the right fit for you.

The bus-factor question

The legitimate concern: "what happens to us if Shawn gets hit by a bus?" The answer has four parts:

1. You already have the source. The codebase keeps working without ongoing architect access. Nothing is in escrow with a kill-switch.
2. The codebase is internally documented. ADRs, glossary, inline comments, OpenAPI specs, a published machine-readable api-summary.json — a new architect or your own team can pick up operations.
3. The codebase is idiomatic. Any senior .NET / React engineer can read and extend it. There are no proprietary frameworks or non-standard languages.
4. Code escrow is available on request for engagements that need it for diligence.

The model

• License-based, not subscription. You pay once for the engagement, you own perpetual usage rights to the codebase your team receives.
• No per-seat pricing. Your team is your team. No "growing into" the next tier.
• No usage caps. No "you've hit 100K requests this month."
• Custom-scoped per engagement. Pricing reflects the shape and duration of your project, not a price list.
• Deployed onto your cloud. Product Perfect doesn't host anything. Your Azure subscription, your data, your control.

What "license" means in plain English

You receive the full source code. Your team commits it to your own git repo, runs it on your own infrastructure, modifies whatever you want, and ships products built on top of it. No vendor kill switch. No "we're sunsetting this." If Product Perfect stops operating tomorrow, your codebase keeps working — you just lose access to ongoing architectural advice.

What you specifically receive on day one

The initial code drop is six concrete deliverables, set up and verified before the architect hands off:

1. AzureSQL Database + CI/CD — restored from a .bak file into your Azure environment, with source control and CI/CD configured for the deployed database.
2. C# API codebase — entire ASP.NET Core 8 solution dropped in, verified to build and run locally, verified to connect to your remote Azure database.
3. CI/CD DevOps deployments — Azure DevOps automated deployment configured for the database, API, WebJobs, and Functions across up to 4 environments included (dev, QA, staging, prod, or your equivalent split).
4. React dashboard codebase — entire CleenUI React starting-point codebase dropped in with the required configuration for leveraging all CleenUI components. Verified to build and run locally.
5. React CI/CD deployment — front-end deployment pipeline configured (Netlify by default; your choice of host works).
6. Developer guidance — direct work with your developers to ensure they're well-adapted to leveraging the entire CleenUI stack. Includes the 20 hours of developer setup time bundled into every license.

What ongoing updates look like

Updates follow a formalized product roadmap. React components ship via Storybook and a versioned npm package; C# and database updates ship as scripts or zipped solution files. Your team chooses when to adopt each update — there's no forced upgrade. The license covers updates indefinitely.

What's explicitly NOT included

So there are no surprises:

• Cloud hosting costs (your Azure subscription)
• Auth0 subscription (third-party, your account)
• AI provider API costs (OpenAI, Anthropic — your accounts)
• External integrations beyond what ships (Stripe, Twilio, HeyGen are wired; you pay the vendors)
• 24/7 support hotline (this is a code-license relationship, not a SaaS subscription)
• Custom feature development (the architect advises; your team builds)
• Compliance certifications (SOC2, HIPAA — codebase is built to support them, certification is your team's project)

What it actually took to build CleenUI

The codebase represents roughly 24 developer-years of focused work: an average of 7.5 developers across 39 months of active development, producing 300,000+ lines of source code, 524 endpoints, 15 modules, 700+ stored procedures, and 60+ accessible React components. That number is the floor — not the ceiling — of what your team avoids when you license rather than rebuild.

The build-vs-license math

A back-of-envelope calculation a CFO can run, two ways:

• By dev-years. 24 dev-years × $300k fully-loaded annual cost = ~$7.2M in engineering cost to recreate the substrate from scratch. Pre-licensing this work at a fraction of the cost is the math behind the engagement.
• By API surface alone. 524 endpoints × ~10 engineering hours each (design + implementation + test + review + docs) = ~5,200 hours. At $200/hour blended senior rate = ~$1.04M for just the API tier. Frontend, database, and background-services add 50–100% more.
• Time cost. 4 senior engineers full-time, ~6 months minimum for the API surface alone. Market opportunity cost of those 6 months often exceeds the engineering cost.
• CleenUI engagement cost. Custom-scoped per project, but reliably an order of magnitude less than the build-from-scratch estimate. Typically a small fraction of one engineer-year.

Quantified outcomes

The exit / diligence story

When an acquirer's technical diligence team looks under the hood, they want to see an identifiable architectural lineage (not "we figured it out as we went"), documented decision records, a real audit trail, a stable data layer, and code an outside team can read. A CleenUI-based codebase clears these bars by construction. The delta between "codebase architected by published expert" and "codebase invented during 14-hour days by the founding team" shows up in diligence valuations.

CleenUI fits when…

• ✓ You're building a B2B SaaS application from scratch, or modernizing off legacy (.NET Framework, WebForms, WCF)
• ✓ Your product needs multi-tenant, auth, audit, RBAC out of the box
• ✓ Your team is 2–10 engineers (works above; works exceptionally below)
• ✓ You want to ship in months, not quarters
• ✓ You're willing to operate the codebase on your own cloud
• ✓ Your tech stack is open to .NET + React (or you're not committed yet)
• ✓ You expect to use AI coding tools (Claude Code / Cursor / Windsurf) heavily

CleenUI is NOT a good fit when…

• ✗ You need a hosted product with no engineering team (use a SaaS platform)
• ✗ You're committed to a stack CleenUI doesn't use (Python / Node / Go / Rust backend)
• ✗ Your application isn't B2B SaaS shaped (consumer social, IoT, embedded, game)
• ✗ You need microservices at scale (CleenUI is a modular monolith)
• ✗ You want to outsource the whole build (this is a foundation, not an outsourced team)

For the 30-minute architecture review

1. Walk through how M01 Security handles multi-tenant isolation for our use case.
2. We have an existing app in [tech]. What's the migration story?
3. Show me one place where customers have struggled with the codebase. What did they do?
4. What's the typical engagement length, and what happens at the end of it?
5. We're considering [competitor]. Where would they be a better choice than CleenUI?
6. What's NOT in the codebase that we should plan to build ourselves?
7. What's the upgrade path if you ship a new version next year?
8. Can you give us 2 customer references we can talk to?
9. How do we handle the bus-factor question internally? What's your stance on code escrow?
10. What's the engagement model after the initial license — ongoing retainer, project-by-project?

For your technical advisor to validate independently

1. Read the code on /api-coverage and /codebase. Does the shape match what we'd want to maintain for 5+ years?
2. Run the architecture dependency graph at /architecture. Does the layering make sense for our domain?
3. Look at the data model at /database. Will our entities fit, or will we be fighting the schema?
4. Test the API in Postman (entry point at /postman). Are the endpoints idiomatic?
5. Try the AI agent skills with Claude Code / Cursor. Does the tooling produce idiomatic code in this codebase?
6. Read the ADRs at /decisions. Do you agree with the architectural choices?
7. Review the integrations list at /integrations. Are our must-have vendors there?