Solutions Architect, Spec-Driven Systems, Practical AI
Mark Hazleton is a Solutions Architect who builds real-world software systems connecting AI, cloud architecture, and production engineering. His work centers on Azure and .NET platforms, AI-assisted development, healthcare systems, spec-driven development, ASLCD, and the Project Mechanics framework he founded to make delivery decisions explicit.
This site is the authoritative home for my professional identity, writing, project systems, and architecture philosophy. The applications I have developed are showcased at MakeBoldSpark, while Make Bold Solutions is the company my wife and I are building around practical software, architecture, and delivery leadership.
My credibility comes from long-running systems, production trade-offs, and the record of writing and open-source work that documents how those decisions are made.
The homepage should make the identity map clear before asking a first-time visitor to choose a path.
A first visit should answer three questions quickly: who I am, what framework I use, and where the evidence lives.
Professional background, architecture focus, and operating philosophy.
OpenThe Adaptive System Life Cycle Development model behind DevSpark.
OpenHow specifications, constitutions, and review gates shape AI-assisted work.
OpenProduction systems and reference implementations from the portfolio.
OpenThe live showcase for applications I have developed across the Spark ecosystem.
OpenThe company my wife and I are building; the full site is coming soon.
OpenArchitecture, AI, .NET, Azure, and engineering notes from the blog.
OpenRepository activity, source code, and open-source work.
OpenWhere I think out loud about architecture, AI, and what building software actually teaches you.
Analytics and development teams operate on the same data with different goals, different time horizons, and different definitions of what matters. This is about that structural gap — and the analytic contract that makes both teams' assumptions visible before something breaks.
The Mountains of Misunderstanding map the gap between what we think we know and what we actually know — a gap that AI widens by packaging fluency as expertise. A year after writing this article, spec-driven development became my structural answer to staying off the mesa.
Getting one .NET site online behind Cloudflare is manageable. Hosting several low-traffic demonstration sites on one Windows VM to keep cost and maintenance low forced me to think less about hosting checklists and more about blast radius, boundaries, and what I would do if one of them ever outgrew this setup.
Each system holds some constraints constant and changes others. MakeBoldSpark is the live showcase for the applications I have developed; this section keeps the architecture evidence close to the reasoning behind those systems.
Visit MakeBoldSparkSpec, build, validate, evolve
DevSpark is an implementation of Adaptive System Life Cycle Development (ASLCD), a full lifecycle model for building software with AI collaborators. It carries intent from specification through implementation, validation, and evolution.
Operational prompt workflows for real applications
PromptSpark.Chat explores how prompt systems behave when they become part of an application workflow. It focuses on structured conversations, reusable prompt assets, and practical integration patterns.
Documentation that becomes implementation context
DocSpecSpark frames documentation as a working system asset instead of a static afterthought. It supports the bridge from architectural intent to implementation-ready specifications.
A controlled frontend architecture comparison
TailwindSpark is a React and Tailwind implementation that consumes shared service patterns while emphasizing composition and utility-first design. Its value is clearest when compared with BootstrapSpark against the same architectural constraints.
In 2002, I founded Project Mechanics LLC to document what I'd learned about delivering complex projects. Over two decades of refinement — across consulting, enterprise, and healthcare — those lessons became a complete methodology.
It covers the full project life cycle, portfolio governance, leadership, change management, and conflict resolution. Not a textbook — a working framework I've used on real engagements.
Explore the methodologySix core disciplines:
I've been writing software since the early 1990s through client-server, the web, cloud, and now AI-augmented development. Each wave brought new tools and new versions of the same fundamental questions about how systems should be structured, how decisions should be made, and how to know when something is working.
I started writing publicly because the act of explaining something is how I find out what I actually understand. The blog posts here are where I work through those questions: architecture decisions, AI-assisted development, production constraints, and the operating habits that make systems easier to change.
More about my backgroundTailwindSpark, BootstrapSpark, PromptSpark, and supporting services make architecture visible by holding some constraints constant and changing others. The point is not to crown a framework; it is to see how complexity moves.
The shared service layer connects WebSpark, PromptSpark, GitHub Repository Spark, and markhazleton.com content. That connection turns portfolio work into a living architecture study.
Explore the Architecture