I'm Mark Hazleton, a Technical Solutions Architect who helps teams turn cloud, integration, modernization, and AI-assisted delivery decisions into systems they can explain, operate, and improve.
I work at the intersection of Azure, .NET, healthcare and enterprise systems, practical AI, and delivery governance. This site collects the writing, project evidence, and frameworks behind that work. 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 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.
Most architecture work is not about choosing a tool. It is about making constraints visible, deciding where complexity belongs, and leaving the next team with a system they can reason about.
Designing Azure-hosted applications, APIs, data flows, and integration patterns with reliability and operability in view.
Learn moreUsing AI tools inside bounded engineering workflows where requirements, review criteria, and architecture decisions remain explicit.
Learn moreHelping teams decide what to keep, what to replace, and how to move without losing the business context embedded in existing systems.
Learn moreApplying Project Mechanics to clarify delivery states, accountability, change management, and leadership decisions.
Learn moreBuilding and documenting small production-oriented systems that make architecture trade-offs visible.
Learn moreTurning implementation work into clear technical notes that help architects, engineers, and stakeholders evaluate decisions.
Learn moreA live set of applications and experiments that show how shared architecture behaves across different frontends and workflows.
Learn moreThe shortest paths into the work: background, frameworks, systems, applications, writing, and source code.
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.
OpenDifferent visitors need different evidence. These paths are organized around the questions technical leaders, peers, clients, and AI delivery stakeholders usually bring to the site.
Use the architecture notes and systems evidence to evaluate delivery governance, cloud trade-offs, and AI adoption without overstating what the tools can do.
ContinueStart with ASLCD, DevSpark, and the controlled Spark comparisons to see how architectural intent survives implementation pressure.
ContinueReview my background, Project Mechanics, and delivery philosophy before starting a conversation about architecture or software delivery work.
ContinueTrace the practical AI work through PromptSpark, DevSpark, and production-focused writing on specifications, review gates, and observable behavior.
ContinueI help teams reason through architecture, modernization, AI-assisted delivery, and the delivery practices that keep production software understandable.
Where I think out loud about architecture, AI, and what building software actually teaches you.
The Agent Skills specification is a welcome step toward portable, reusable AI capabilities. But enterprise software delivery needs more than portable skills — it needs orchestration, governance, and lifecycle continuity. This article traces where DevSpark sits in that emerging landscape and why the distinction matters.
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.
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 DevSpark and ASLCD