I needed a fast way to create diagrams. The first proof of concept of DrawmaticAI took a few hours. By the end of the next day, there was an MVP working.
That is the thing about building a use-case-specific tool instead of fighting a general-purpose platform: no compromises for hypothetical users. You solve the actual problem in front of you.
And because it is iterative, adding features when needed is straightforward. Need the AI to follow complex multi-step diagram instructions — swim lanes, parallel execution tracks, decision trees, retry loops, synchronisation bars — and still produce valid, portable output? You build that. XML repair when the model truncates mid-diagram? Done. Retry logic with graceful degradation so a partial diagram renders instead of nothing? Added. Multi-user real-time collaboration and cursor positioning? That too. No roadmap committees, no feature votes — just build.
What sets this apart from a side project thrown together on a whim is that it was built following tried and tested SDLC processes from day one. Unit tests. UI tests. Code reviews of my own changes with proper diff analysis. The kind of discipline most people reserve for "real" software, but it was real from the start.
The benefits of this approach:
- Self-hosting means your data stays yours. No sending proprietary architecture diagrams through a third-party AI API. Privacy is not an optional setting in a preferences menu.
- Running your own infrastructure beats paying per-token for every diagram. The cloud cost arithmetic is straightforward when you keep computation in-house.
- The output is portable. Diagrams are standard Draw.io XML — not locked inside a proprietary tool, not a screenshot. You own the file.
- Multi-user support with role-based access means teams can collaborate without handing control to a SaaS vendor.
This was never meant for general consumers. But the pattern applies at a company level: building internal enterprise-quality apps that are purpose-built, secure by design, and owned by the organisation. Why not build what you actually need?
We talk a lot about "enshitified" products. But the answer is not just removing dark patterns. It is building things right from the start: tools that are secure by design, respectful of user privacy, useful for their specific job, and owned by the people who use them.
It started with a problem and curiosity. A few hours later, I had a POC. One day later, I had an MVP. That is the iterative development loop that everyone should experience at least once.
A local LLM following a detailed, precisely specified diagram — multiple swim lanes, parallel workflows, conditional branches, synchronisation points — and producing a complete, portable diagram in a matter of minutes. Something that would have taken hours to produce by hand.