Earlier this year we kept having to re-work our AI coding assistant’s implementation of every new Bottom Sheet we were adding to the app.

We use a custom BottomSheet component on our mobile app, a wrapper around React Native Bottom Sheet that abstracts the structure and parts of the layout. Every time we asked the AI to add a new sheet, it would re-implement the library from scratch. We’d revert the change. Next session, we’d ask for a different sheet. The AI would re-implement the wrapper again. Sometimes it broke the existing ones in the process.

It wasn’t a knowledge problem, we knew exactly how we wanted these components to be implemented. We just had to repeat ourselves over and over again. Yes code was written fast but we were losing the time gained by having to explain ourselves from scratch for each new case.

The honest read on what was happening: we had no machine-readable record of how to implement these Bottom Sheets in our app, what to abstract in that wrapper and what to leave customised by the inside component. The AI couldn’t reason about a convention it had never been told about. We’d been treating it as a faster typist when its actual constraint was context.

That realization changed how we work. Three months later, we spend 80% of our time stirring feature’s scope and iterating over the specs and 20% of the time implementing, the inverse of how we used to work until AI showed up. The mechanism isn’t a smarter model or better prompts. It’s a deliberate investment in the context that agents read before they touch anything.

If writing code is no longer rationed, what is the new shape of engineering work, and what new form of debt does it produce?

This is the first piece in a five-part series on what we built, what we learned, and what we still don’t know. Today: why documentation became the infrastructure of how we work, and what we actually centralize in it.

Documentation was the bottleneck we kept ignoring

Software development has had a technical documentation problem for decades, and it’s not a tooling problem. It’s a priority problem.

The traditional flow is well-understood. A product owner writes a spec. A designer translates it into screens. An engineer translates those into code. At every handoff, context degrades. The PM didn’t realise that by adding some nice to have requirements he was adding the overhead of having to create new tables or refactor the whole data model. The designer specified a navigation that conflicts with the current navigation structure.

Documentation was supposed to prevent this but it’s a challenge to keep maintaining it. The codebase was the source of truth, and the codebase could only be read by engineers. Knowledge lived in people’s heads, surfaced in chat threads, evaporated when someone left.

When AI coding assistants arrived, we used them the obvious way: write code faster. The result was instructive. We generated more code, but the spec-to-implementation gap didn’t close. We spent less time typing and more time correcting.

The uncomfortable insight: we thought AI was all about producing code that works fast but the real challenge is engineering its context so that it produces code that works fast but that leverages your engineers knowledge and adheres to your conventions and patterns so that your codebase stays consistent and clean. This is what in turn makes your system robust and every next move easier and easier.

So we stopped optimizing for code output and started investing in documentation infrastructure.

What "80% planning, 20% coding" actually means

It doesn’t mean more meetings. It means different artifacts, maintained at a different cadence, by a different group of people.

The PM starts a session to start ideating over a new product change. He/she goes back and forth about the why, for who, the scope and finally gets to the technical spec, the "how". This is the moment where AI leverages the documentation and other artefacts to design a solution anchored in the reality of the codebase. It suggests the changes to the system documentation to deliver this feature. The engineer can review that proposal and course adjust if needed.

When implementation begins, the developer pastes a refined-issue URL into the AI tool. The agent reads the issue which contains the why, what and how all in the same place. It has highly detailed instructions that a human could almost never write which allows the coding agent to implement the changes almost in one shot. The 20% is the coding step itself, which becomes largely mechanical when the spec is precise.

This only works if the documentation is precise and current. When it drifts, agents start hallucinating confidently, which is harder to catch than a compile error. The cost of poor documentation is no longer just human confusion. It’s bad code that looks right.

That’s what we mean by context infrastructure. The docs aren’t a reference artifact. They’re the literal input agents consume before taking action.

What we centralize, and why

Our documentation lives in a single repository, a Central Hub, separate from any product code. The same hub serves multiple codebases (in our case, a backend, a mobile app and a web app). When a convention gets updated, every agent on every project picks it up immediately.

The hub holds two layers: company and product context (vision, mission, personas and JTBD, design guidelines and brand tone of voice) and architectural (system documentation structured following the arc42 framework). Inside arc42 we use C4 to draw the architecture diagrams for each section, and ADRs to populate the dedicated decisions section (§9). None of these frameworks are novel on their own. What’s novel is that we’re not updating them after implementing a new change, we use them as context to write the spec for agents.

• Vision, mission, brand, personas and JTBD, design guidelines and brand tone of voice. The company’s identity and direction: who it’s for, why it exists, how it presents itself. The Product Manager agent reads these before scoping a feature, and stress tests the proposed work against strategic pillars and current usage data. Work that doesn’t align with any pillar surfaces immediately as a conversation, not as something that quietly sneaks into a sprint.

• System documentation following arc42. Stakeholders, quality goals, system decomposition, technology decisions, risks, and a shared glossary. The Architect agent reads the relevant sections before proposing any spec. arc42 is a free, open-source template that’s been around for over a decade. We adopted it because it gave us a structure we didn’t need to invent.

• Diagrams in C4. arc42 calls for architecture diagrams in several sections; we draw ours using C4. It visualizes systems at four levels of detail (Context, Containers, Components, Code). Each level gives agents a map at the right zoom level: broad enough to understand boundaries, precise enough to understand business rules. We render the diagrams as Mermaid in markdown so they live next to the prose and version-control cleanly.

Of these formats, ADRs are the one that pays off most often. Most "AI hallucinations" we see in the wild aren’t really hallucinations. They’re decisions an agent made because nothing told it which way had already been chosen. An ADR collapses that ambiguity to a citation.

What this looks like in practice

A recent feature: a notification system to re-engage users after install.

Our human PM opened a session with the Product Manager agent. They worked through whether to build it (alignment with strategy and vision), what notifications triggers to build in which order, what success looked like (specific engagement metrics). The Architect agent reviewed feasibility against the existing architecture. The Developer agent explored the backend for existing event hooks that could trigger notifications. The session produced an ADR on the notification service choice, an update to the building block view, and three glossary entries.

From that spec, the Project Manager agent broke the work into Linear issues. Each issue referenced the relevant arc42 sections, the new ADR, and the acceptance criteria the PM session had defined.

When implementation began, the developer pasted the first issue’s URL into the tool. The agent read the issue, loaded the referenced arc42 sections and ADR, and applied the patterns defined in our shared rules. It wrote code that matched the conventions on the first pass. The code reviewer agent flagged one error-handling inconsistency on review; the developer agent fixed it. The PR merged.

We don’t have clean apples-to-apples comparison data, but features that used to take a day or more now routinely ship in an afternoon. More importantly, they ship in a state we don’t have to argue about: they follow the conventions we already documented. This eventually means less debates and re-work during pull request review.

The new failure mode: context debt

This isn’t free. We’ve replaced one kind of debt with another.

Technical debt used to cause bugs and decrease velocity. Now it also confuses agents and can introduce more tech debt. When the codebase has inconsistent patterns, agents don’t know which to follow. They pick one, and if it’s the wrong one, the team spends hours unwinding an implementation that went sideways. Tech debt is paid twice: once in defects and a second time when planning the next move.

The new form of debt is context debt: documentation that’s stale, incomplete, or ambiguous. It compounds the same way technical debt does.

There’s one extra propagation path: one agent’s hallucination, once written into a section or an ADR, becomes the next agent’s source of truth.

The honest version of "documentation-first development" is that drift is now visible (agents make bad specs). Even though it’s now easier than ever to maintain documentation thanks to AI and automation pipelines, it still requires a lot of focus and critical thinking to maintain the context infrastructure. During each session it’s about recognising missing or wrong context and creating tasks to improve the central hub so we don’t have to repeat ourselves next time.

What we don’t know yet

Three months in, four people, a greenfield project. The limits we know about:

• Scale is unproven. This workflow works at four but will probably need to be re-structured for a bigger team.

• Greenfield helps. We had no legacy documentation to retrofit. Applying this to a ten-year-old codebase is a fundamentally different problem.

• The cost of staying current. Right now we can maintain the documentation because drift is visible. If team pace increases, the maintenance burden could compound faster than we can absorb it.

We’re sharing what we learned because the direction seems clear, not because we’re certain it scales. The bottleneck was never typing speed. Code was rationed, and we mistook the rationing for the work. The work is shared understanding, built by humans, together.

Next in this series, in two weeks: Agentic Product Management. If documentation is the foundation, what does the layer above look like? What changes about product management when refinement happens with agents in the room?

Every Dashboard I’ve Built Has the Same Problem

Here’s a story you’ve probably lived. You join a project, and someone asks for a dashboard. You spend a few days figuring out the data source, writing API calls or SQL queries, choosing chart types, wiring up data mappings, tweaking the layout, styling it. You ship it. Everyone’s happy.

Two weeks later, someone wants different metrics. The team pivots to tracking something else entirely. You rebuild half the dashboard. Then the other half. Then you start wondering why you’re spending more time maintaining visuali

zations than building the product itself.

Charting isn’t the hard part. Libraries like ECharts or Recharts can render beautiful charts from a JSON config. That’s a solved problem. The hard part is everything around the chart: the manual mapping between “what I want to see” and “how to fetch and display it.” Figuring out the right API call, extracting the right fields, choosing the right chart type, mapping data to axes, laying it all out. That’s where all the time goes, and every time a requirement changes, it breaks.

I kept running into this, and at some point the question shifted: what if I could just describe what I want to see, and the system figures out how to get it and show it?

That question is what led me to build Mystique.

Let the Model Do the Mapping

Charting libraries already speak JSON. ECharts takes a JSON options object. Grafana dashboards are JSON files. This isn’t new. What’s new is that language models have gotten good enough at structured output to generate these configs reliably from natural language.

That’s the entire idea behind Mystique. You describe a dashboard in plain English. A language model generates a valid JSON config: which APIs to call, what fields to extract, how to map them to chart axes, what chart types to use, how to lay it all out. The config gets validated, the data gets fetched, and the charts render.

The model doesn’t just pick a chart type. It figures out the entire pipeline. When you say “show me product prices and ratings,” it identifies the right API endpoint, determines which response fields to visualize, decides whether a bar chart or scatter plot fits better, maps fields to x and y axes, and arranges everything in a responsive grid.

The key mechanism that makes this reliable is structured output. I’m using the Vercel AI SDK, which lets you pass a Zod schema to the language model and constrain its output to conform to it. The model can only produce JSON that matches the contract. This isn’t a “generate some JSON and hope it parses” situation. The output is structurally guaranteed to be valid.

To help the model produce good configs (not just valid ones), I use few shot examples in the prompt: natural language descriptions paired with high quality dashboard configs that teach the model what good looks like. The temperature is set low, 0.2, for consistency.

Watching a Dashboard Build Itself

The part that really sold me on this approach is progressive streaming. In the demo application, the AI doesn’t generate the entire config and then render it. The config streams in token by token, and the dashboard renders as the AI thinks. You type a description, hit generate, and charts start materializing on screen while the model is still working.

This required a bit of care. You can’t render half a config or you’d get missing chart references and broken layouts. So there’s a guard that checks whether enough structure has arrived before attempting to render. It waits until the config has at least one complete chart with field mappings, a data source with a URL, and a layout position. Only then does the dashboard appear. As more charts stream in, they fill the grid progressively.

The experience of watching a dashboard build itself from a sentence is surprisingly compelling. It makes the abstract idea, “describe what you want, get a visualization,” feel real.

Dashboards That Don’t Need to Exist Forever

This is the paradigm shift I’m most excited about. If the AI can reliably generate valid configs from descriptions, then dashboards become disposable. You describe what you need right now, you get it right now, and you discard it when you’re done. No maintenance burden. No stale metrics. Just a fresh answer to a fresh question.

When you say “show me product prices by category,” you’re expressing intent, not writing configuration. You don’t need to know the API schema. You don’t need to know what chart type works best. You just need to know what question you’re trying to answer.

Today Mystique works with REST APIs. The architecture uses pluggable data adapters, which means SQL and database connectors are the natural next step. Imagine describing “show me monthly revenue by region” and the AI writes the SQL query, fetches the data, and renders the chart.

Mystique

Have questions or want to discuss potential collaborations? Feel free to reach out in the comments below or connect with me directly!

Linkedin | Portfolio

Github

Strapi has gained popularity as a headless CMS for rapid application development, making it a strong candidate for Minimum Viable Products (MVPs). Because of its JavaScript-based, open-source nature, it can adapt quickly to changing requirements — a critical factor when your primary goal is to validate ideas and gather user feedback.

In this post, I'll walk you through how you can deploy Strapi on AWS to achieve flexibility, scalability, and cost-effectiveness.

Why Use Strapi for an MVP?

An MVP often has two main objectives: reduce time to market and validate product-market fit. Strapi fulfills these needs by offering:

Rapid Development: Its intuitive admin panel and pre-built APIs reduce the need for extensive boilerplate code.

Adaptability: You can customize data models and permissions without being locked into proprietary ecosystems.

Neutral Ecosystem: Strapi runs on Node.js, which makes it easy to integrate with other services across different cloud environments.

These traits make Strapi one of several potential solutions for MVPs. While it's not the only headless CMS on the market, its flexibility makes it worth considering.

Key AWS Services for Deployment

Here are the core AWS services that form the backbone of this architecture:

Amazon Elastic Container Service (ECS): By containerizing Strapi, you can simplify your deployment and scale your containers in response to traffic spikes. ECS orchestrates containers, reducing manual server management.

Amazon Elastic Container Registry (ECR): This is where you can store container images securely and integrate seamlessly with ECS for automated deployments.

AWS Fargate: As a serverless compute engine, Fargate allows you to run containers without provisioning or managing servers. It also scales automatically based on defined CPU and memory requirements.

Amazon RDS: For database management, RDS takes care of updates, backups, and failover. Popular engines like PostgreSQL and MySQL are supported, ensuring Strapi's database remains robust and easy to scale.

Amazon S3: When handling media files, S3 provides a cost-effective storage solution. It's particularly useful for large file uploads, backups, and static asset hosting.

These services, when combined, form the backbone of a flexible, scalable architecture. Feel free to substitute or remove services based on your project's unique needs and constraints.

Benefits of This Approach

Cost-Effectiveness: By leveraging serverless services like Fargate, you only pay for what you use. Autoscaling features reduce expenses during low-traffic periods.

Ease of Scaling: ECS with Fargate can automatically adjust container instances according to demand, preventing downtime or performance bottlenecks.

Adaptability: AWS offers a broad range of services, giving you the flexibility to add or swap components (e.g., switching to Amazon DynamoDB if you prefer a NoSQL approach).

Reduced Maintenance: Offloading tasks like database patching and server updates to managed services lets you focus more on product development and less on infrastructure.

Wrapping Up

Whether you're building an MVP or looking for a robust content management layer, Strapi deployed on AWS can be a compelling choice. It delivers the speed, flexibility, and scalability many teams look for in early-stage projects, while also providing an adaptable foundation for future growth.

Still, it's just one option in the world of headless CMS solutions, so be sure to evaluate your requirements and budget before committing.

Have questions or want to discuss potential collaborations? Feel free to reach out in the comments below or connect with me directly!

Linkedin | Portfolio