DEV Community: Douglas Rosenberg

One App, Two Audiences: Building a Customer Intake Backend with a Personal ERP Inside It

Douglas Rosenberg — Mon, 12 Oct 2026 01:15:45 +0000

Update (2026-10-11): the two pieces this post lists as still ahead are done. The app has been live at admin.dougrosenbergdev.com since 2026-09-25, and a GitHub Actions CI/CD pipeline (build and test on every push, a manually triggered deploy using OIDC federated login with no stored client secret) was confirmed working that same day. The sections below are the original text. The client portal is still a stub, and the MCP server is still a plan, not a build.

My newest project isn't for a client — it's for me. customer-intake-backend is a small .NET app that does two jobs: it's the public lead-intake system for two different businesses (my dev-consulting work and music-booking inquiries from the bands I play in), and it's also home to a private personal ERP I use to track my own freelance pipeline. Those two things share a process and a repo. They do not share a data boundary — and how I enforced that, not just declared it, is most of this post.

One Leads Table, Two Businesses

The public-facing half is straightforward: a shared Leads table tagged by Source, so a booking inquiry from the band's site and a dev-services inquiry from this one land in the same schema instead of two one-off tables that happen to look identical. Both dougrosenbergmusic and Guacamayo's site are static (Astro on Cloudflare Workers) and can't run C#, so this exists as its own deployable service they call into over HTTP — POST /api/leads, CORS-restricted to the sites that are allowed to post to it, rate-limited, with the unauthenticated GET locked to development only.

Hard Problem #1: Keeping a Private ERP Inside a Public-Facing App

The personal ERP needed somewhere to live, and the obvious-sounding answer — a fully separate app — turned out to be the wrong default once I actually weighed it. A second repo means a second deployment, second auth, second CI/CD, all for a single-user internal tool. What the sensitivity of the data (real client pricing, an active pipeline) actually requires isn't process isolation, it's data isolation. So the personal ERP lives in the same repo, same deployment, same login — but on its own DbContext and its own database, with nothing shared at the EF Core layer.

Declaring a boundary and enforcing one are different things, so I didn't stop at the design doc. There's an architecture test (NetArchTest.Rules) that fails the build if the public-facing Components.Pages namespace ever references the personal ERP's types, or if the personal ERP ever reaches for the public CustomerIntakeDbContext. And I didn't just trust that the test worked — I deliberately introduced a violation, watched the build fail, then reverted it. If I ever copy-paste the wrong query, or an AI-assisted edit reaches for the wrong context, the build catches it before it ships. That's the realistic failure mode I was actually guarding against — not an attacker, just an ordinary solo-dev mistake at 11pm.

The honest gap: none of this protects against the process itself being compromised — a dependency exploit gets an attacker both connection strings regardless of any C#-level type rule. That's accepted, not overlooked, and the upgrade path if the risk profile ever changes is narrowing network reachability, not re-architecting into a separate app.

Hard Problem #2: A Status Field Can't Tell You When

The original Leads table tracks pipeline state with a single mutable Status enum — New, Contacted, Converted, Closed. Every change overwrites the last one. There's no record of when a lead actually moved from New to Contacted, or what happened in between. Fine for a low-volume, single-admin intake flow — but designing the personal ERP's client pipeline from scratch, I didn't have to inherit that limitation.

So ClientLead.CurrentStatus is a cached projection, not the source of truth. The real source of truth is LeadEvent: one row per thing that actually happened — outreach sent, a gig played, a proposal sent — each with its own date. Current status gets derived from the latest event instead of written to directly. The payoff is that questions like "how long between outreach and conversion" are answerable for free, straight from the schema, with no extra tracking bolted on. The cost is real too: every status change now means writing an event row instead of setting a field, and if something ever writes to CurrentStatus directly instead of going through the event-append path, it can drift from the log. That's a discipline I'm holding by hand for now, not something the database enforces yet.

Hard Problem #3: Azure Assumed My Zip File Was Source Code

Deployment was the least interesting problem to design and the most annoying to actually execute. The plan was ordinary — Azure App Service plus Azure SQL, reusing an existing free-tier plan for near-zero incremental cost. Getting there wasn't ordinary. The CLI path (az webapp deploy, both locally and from Cloud Shell) kept invoking a server-side build step that failed with "Couldn't detect a version for the platform 'dotnet'" — because the zip I was uploading was already-published output (compiled DLLs), not source, and the build tool had nothing buildable left to detect. It wasn't looking for what I'd actually given it.

What worked was going around that path entirely: Visual Studio's built-in Publish, targeting the existing App Service over Web Deploy, which hits the classic deployment endpoint directly and skips the server-side build step altogether. Not the CI/CD story I eventually want (that's still explicitly deferred), but it got real code onto a real server without fighting a build system that was solving a problem I didn't have.

The Stack

Backend: ASP.NET Core 10 minimal API + Blazor Server, one process
Data: EF Core 10 + Azure SQL (two separate databases: intake + personal ERP)
UI: MudBlazor, restyled to this site's navy/teal/Montserrat tokens
Auth: ASP.NET Core Identity, Admin/Client roles
Testing: unit tests on the service layer (SQLite in-memory), architecture tests enforcing the ERP boundary at build time
Hosting: Azure App Service, Web Deploy

What's Actually Live

As of this post: real auth is in place (Admin and Client roles, though the client-facing /portal is currently a stub, not wired to real data). Leads and Companies have full CRUD with notes and an event log. The personal ERP's client-pipeline tracking is live with its own boundary-tested database. The whole thing is deployed and reachable — the custom subdomain and a proper CI/CD pipeline are the two pieces still ahead of it.

What's Next (and Not Built Yet)

I've been sketching a custom MCP server on top of the personal ERP's data — list_leads, get_lead, add_event-shaped tools sitting on a domain model that's already close to tool-shaped. Microsoft co-maintains an official MCP C# SDK, so it stays in the same skill-building lane as the rest of this project rather than being a detour into a different stack. But I want to be straight about where it actually stands: it's a plan, not a build. It's sequenced deliberately after auth and deployment — both now done — specifically so there's something real and access-controlled to attach it to before any MCP client can reach personal data over the network. When it's built, it gets its own post.

The Takeaway

None of this was hard in the "clever algorithm" sense. It was hard in the more common way real projects are hard: deciding where a boundary actually belongs, then proving — not just declaring — that it holds; picking a data shape that survives a question you haven't asked yet; and occasionally getting stopped cold by a deploy tool that assumed something about your inputs that wasn't true. If you're building something similar — a side project sharing infrastructure with something more sensitive — the architecture test is the part I'd steal first. A comment saying "don't reach across this boundary" survives until someone forgets. A build that fails does not.

I build custom business software and ERP-style systems for small organizations, and I'm based in the Chicago area. If that's what you need, the details are on my consulting page.

Rebuilding My Own Musician Site: From a Blazor Template to a Verified Astro Build

Douglas Rosenberg — Sun, 11 Oct 2026 03:57:03 +0000

Above: dougrosenberg.com's old Blazor-template site, archived here for reference before the rebuild replaced it.

Update (2026-10-10): the rebuilt site went live at dougrosenberg.com the evening this was first published, and the Cloudflare Worker-backed contact form shipped that night. The "What's Still Open" section below is the original text; only the missing sheet music is still open.

The Starting Point

dougrosenberg.com is my other site — under a different hat, I'm a saxophonist, composer, and educator, and that's where that identity lives online. It's been running on Blazor WebAssembly on top of a stock component template: the same rounded glassmorphism cards, the same corner-blur decoration, the same floating circular chat launcher you'll find on a thousand other template-based sites. It worked. It just didn't read as built for anyone in particular — real content (a working musician's bio, performance history, a full sheet music library) sitting inside a shell that could have belonged to anyone.

What Actually Changed

The rebuild (Astro, deployed to Cloudflare Workers) keeps every piece of real content — bio, performance credentials, albums, teaching history, sheet music, photo gallery, contact — and gives it an identity built around the one thing that's actually distinctive about the site: notation. A fixed nav rendered as icon-marked notes sitting on staff lines, a full-bleed broadcast-graded hero photo instead of a generic template hero, and a self-hosted type system (a display serif, a body sans, a monospace for the nav) instead of a default Google Fonts stack.

The Technical Migration

Blazor WebAssembly ships a full C# runtime to the browser for what is, in the end, a static content site — the same structural mismatch I wrote about auditing on my portfolio site. Astro prerenders to static HTML served straight from Cloudflare's edge instead, and that switch is what made the rest of the work verifiable instead of assumed:

Lighthouse CI run against the production build on every pull request — 90+ performance/best-practices/SEO, 95+ accessibility, measured, not estimated
A 36-test Playwright end-to-end suite covering navigation, gallery, and search behavior, run against a real browser at real viewport widths on every PR
A real Content-Security-Policy with sha256-pinned inline scripts, HSTS, and the rest of the security-header baseline, checkable in the response headers

A Concrete Example: Verifying an Optimization Actually Works

The sheet music library alone was 88MB of scanned PDFs and photos. The obvious move is “just recompress everything” — and it's the wrong move, because sheet music that's actually illegible defeats the point of the feature. Instead of a bulk pass, I wrote a script that recompresses a candidate file, re-renders it, and pixel-diffs the result against the original — it only keeps the change if the render comes back near-identical. Most of the payload turned out to already be JPEG-compressed inside its PDFs, so there was nothing safe left to win without heavier tooling. But the same script caught something real: one file had two images stacked at the exact same position on the page, which looked like a redundant duplicate. Deleting the “duplicate” actually changed what rendered, and the verification step correctly rejected that change and left the file untouched. Three other files did get real, verified reductions — one JPEG dropped 44.5% with no visible difference. The tool earned its keep by refusing bad changes as much as by accepting good ones.

What's Still Open

Being honest about where this actually stands: the sheet music library is still catching up to what's live on the old site — seven pieces are missing, pending source files. Contact is currently a plain mailto: link rather than the Cloudflare Worker-backed form I've built elsewhere. And the domain itself hasn't moved — the new build is live only on its Cloudflare Workers subdomain, since pointing the real domain at it is a real production step I'm not taking without deliberately deciding to.

The Takeaway

A template gets you to “functional” quickly, and that's a legitimate reason to start there. But functional and distinctive are different bars, and closing that gap took more than a redesign — it took a foundation that could actually be checked: real performance numbers instead of assumed ones, a real test suite instead of “looks fine,” and a verification step even on something as unglamorous as image compression. If you're wondering whether your own site's template is quietly costing you, that's the actual question: not just how it looks, but whether you can prove what it does.

I build custom websites for working musicians and bands, and I play in several Chicago bands myself. If that's what you're after, the details are on my musician websites page.

Enterprise Engineering Discipline, Small-Business Budget: How I Approach SMB Web Development

Douglas Rosenberg — Mon, 28 Sep 2026 12:44:19 +0000

If you're a small business owner comparing a website builder against a five-figure agency quote, there's an option in between that doesn't get talked about enough: hire someone who's spent years building software for organizations that genuinely can't afford to get it wrong, then apply that same discipline at small-business scale and price. That's specifically what I do. This isn't a pitch — it's the honest case, backed by real projects rather than adjectives.

Two Worlds, One Set of Habits

By day, I build full-stack systems for organizations where mistakes have real consequences: a secure data-masking pipeline and 50 custom reports relied on by 500+ staff at a global nonprofit's ERP system, a Fortune 10 client's document-processing platform, a manufacturing ERP rebuilt from the ground up. Off the clock, I'm a saxophonist and composer who plays in several working Chicago bands.

Those two worlds punish sloppiness in the same shape, just at different stakes: a report that's wrong at 2am for 500 staff, or a wrong chart in front of a paying crowd on stage. Both teach the same habit — build it right the first time, verify it, don't ship a guess.

What "Enterprise Discipline" Actually Means at Small-Business Scale

This isn't about over-engineering a five-page marketing site. It's specific, checkable things: security modeled correctly even on a $1,500 project (the same thinking behind that ERP data-masking pipeline, scaled down), performance budgets verified with real tooling instead of eyeballed — I wrote up a concrete example of a script that pixel-diffs image compression before accepting any change, rather than trusting a bulk pass — and accessibility built in at a WCAG 2.1 AA baseline, not bolted on after a complaint.

This is the whole thesis behind Haxbyte, the studio this work is delivered under: small business owners don't need enterprise complexity, but they shouldn't have to settle for generic, slow, or fragile sites either. Haxbyte documents a four-step build process — scope it in writing, build the thin slice, load it like it's real, ship then write it up — and every SMB project follows it.

Proof, Not Promises

Three real projects, not hypotheticals:

Sonus Construction Group — a general contractor whose real audience is investors and developers doing diligence, not homeowners browsing a portfolio. The site is built as an editorial one-pager instead of a generic contractor template, because that's what actually earns trust with that audience.
Hardware Etc — as of December 2021, this was a single unstyled placeholder page (the archived version is still up). It's now built for two real audiences — spec-writers doing desktop research and field crews checking specs on a phone mid-install — with a private-label catalog organized for high-volume procurement browsing.
ArborKin — not client work. A private, invite-only family tree app I built and shipped end to end, used by real people, with a custom C# layout engine instead of a JS graph library. It's the proof that this isn't theoretical: I ship and maintain real products, not just deliver client specs.

Why This Combination Actually Matters for You

Most small businesses get stuck choosing between two bad options: a cheap templated site that can't grow past a certain point, or an agency quote sized for a budget they don't have. Custom development from someone who brings enterprise-grade practices earns its cost specifically in the gap between those two — real integrations, real security, a site built to hold up under actual traffic and scrutiny, at project-based pricing (typically $750–$3,000, scoped after a free discovery call) instead of an enterprise retainer.

Frequently Asked

Do I need a fully custom build, or would a website builder work fine for my business?

Sometimes a builder is the right call — both Sonus Construction Group and Hardware Etc, above, are built on Squarespace, and that was the correct choice for those projects. Custom development earns its cost when you need something a template genuinely can't do: real integrations, custom functionality, or a site that has to hold up under real traffic and security scrutiny.

What does a small business web project actually cost?

Project-based custom builds typically run $750–$3,000, scoped after a free discovery call — see the full breakdown on Services.

Why does enterprise ERP experience matter for a small business website?

Because the failure modes are the same shape at different stakes — a wrong report relied on by 500 staff and a small business site going down during its busiest week both come down to the same discipline: test it, verify it, don't assume it works.

Do you maintain the site after launch?

Yes — ongoing support is available as a monthly retainer covering updates, security patches, and small enhancements; see Consulting for details.

The Takeaway

If this sounds like the kind of discipline you want behind your next site, the fastest way to find out is a free discovery call — reach out via Consulting or Services.