From Monoliths to Micro-Apps: A Tour of What I'm Building

Hello, my name is Dave Jackson. I'm a long-time tech enthusiast with a few decades of experience coding in multiple tech stacks for several industry verticals — across start-ups, mid-size Kansas City companies, and multi-national enterprises. I'm writing this as the first in a short series introducing the projects I'm actively building, the books I'm writing alongside them, and where I'm headed next. If you're looking for a freelance architect or a full-time hire who can take an idea from a whiteboard to a working product, this is the overview — the deep dives follow over the next few weeks.

What ties all of this together is a single conviction: in my experience, the most successful projects I've worked on treat architecture as a discipline you practice on real, shipping software — not a slide deck you produce once and never revisit. Everything below is something I've built, am building, or am actively drafting, not a hypothetical.

Current Projects

AI-Native SaaS Apps

Architecture: CQRS-Driven NestJS and Angular

My flagship current project is Prompt Workbench — a platform for managing, versioning, and testing the prompts and system instructions that drive LLM-powered features, built as a single NestJS API paired with an Angular front end. CQRS (commands and queries flowing through @nestjs/cqrs) keeps each capability — red-teaming a prompt, classifying a failure, scoring a benchmark — behind its own handler rather than one sprawling service class. Underneath it sits a multi-provider AI router I built so the platform isn't locked to a single vendor — it routes across Anthropic, Cerebras, LM Studio, Ollama, and OpenAI, resolving deterministically to whichever provider owns the requested model and failing fast with a clear reason code (model not found, provider restricted, capability mismatch) instead of silently falling back to a different model than the one you asked for.

What makes this project different from a typical CRUD SaaS app is where it came from: it's the direct result of the research I did while writing PromptOS (more on that book below). Every prompt pattern, anti-pattern, and debugging ritual I documented in that 23-document manuscript got built into this platform as a working feature, not just a chapter — the book and the code have been developing together.

As a side note: I also built and shipped Job Search Studio, a job-search automation platform, for a more specific reason. Watching the latest wave of AI-driven layoffs hit experienced developers — people who knew their companies' systems and customers better than anyone — I wanted to build something useful for the people on the receiving end of those decisions. If you're an employer reading this: before you lay off the people who hold your institutional knowledge in favor of a model that doesn't, consider the cost of having to rebuild that knowledge from scratch. #TrainAndRetain your talent. It's usually cheaper than you think, and the alternative is rarely as cheap as it looks on a slide.

Domain-Specific Languages

VS Code Compilers, Interpreters, and Tooling

The second thread is developer tooling: building a Domain-Specific Language, LeanAgileScript, for describing user stories and acceptance criteria in a structured, machine-readable format, with a full VS Code language extension — grammar, parser, and language services built on Langium. The goal is to let a product team write specifications that are simultaneously readable by humans and directly executable as acceptance tests, closing the gap between "what we agreed to build" and "what the tests actually verify."

That extension is one piece of a larger suite I'm building as white-label VS Codium extensions: a Prompt Studio for managing and versioning LLM prompts, an Infographic Studio for generating publication-quality SVG diagrams from structured input, and a Compliance Studio that runs automated architecture and standards review against a live project graph. They share a common platform layer — an event bus host, a local LM bridge, and a runtime router — so each studio is a thin, focused tool rather than its own monolith.

One constraint shapes all of it: offline-first is not optional. Every studio has to work fully on a laptop with no network connection, which rules out shortcuts you'd normally take for granted in a hosted SaaS app. At a high level, that mandate shows up as:

• An AI Chat Component — a shared sidebar panel any studio can plug an AI participant into
• An AI Provider Router — routes each call to whichever model backend is actually available
• Local inference via Ollama and LM Studio — so "offline" means fully functional, not degraded
• UI and API code reuse with the SaaS apps — the extensions run the same Angular components and NestJS application logic as their SaaS counterparts, not a rewritten subset
• A bundled NestJS sidecar — each extension can spin up its own local backend process instead of depending on a hosted service
• An API router with two paths — offline calls go to the local sidecar; online, licensed use routes to the cloud API gateway and microservices instead

I'll go deeper on this architecture in the VS Codium Extension Suite deep dive later in this series.

Books in Progress

Writing the code is one way I work through an idea; writing it down for other people is another, and I'm doing both right now.

PromptOS: A Complete Operating System for Prompt Engineering is a practitioner's reference for prompt engineering and multi-agent system design — 23 documents covering everything from core prompt patterns through adversarial security testing, behavioral benchmarking, and production observability for LLM-powered systems. It's the book I wished existed while I was building the AI router above; most of what's in it came directly out of debugging real prompt failures in production, not from theory.

The Lean-Agile MVP Revolution: What Every App Founder Should Know is aimed at app founders and technical leads — it walks through the disciplines that separate a successful product from an expensive technical failure: validated business strategy, lean discovery, acceptance-test-driven development, clean architecture, and data-driven adaptation, all following a single running example product from first idea through its first ninety days in production. I'm on the fifth draft now, with full infographics and a print-ready layout in progress.

What's Next: Smart Home

Looking ahead, I'm starting to sketch out a smart home project — moving the same architectural patterns I use for SaaS (event-driven, local-first, vendor-agnostic) into a physical device context. I don't have a working prototype to show yet, so I'll say this honestly: it's early. But the underlying question is the same one that drives everything above — how do you build systems that stay useful and maintainable long after the first version ships? I'll have more to share on this once there's something real to show.

What's Coming in This Series

Over the next several weeks, I'll publish a deep dive into each of these in turn: the AI-native SaaS architecture and multi-provider router, the VS Codium extension suite and the DSL that started it, both books, and where the smart home project lands once it has real shape. If any of these resonate with a project you're hiring for, I'd love to hear about it — and if you've tackled similar problems yourself, I'm genuinely curious how you approached them. Good luck out there, and stay tuned...