4 Weeks to Migrate. 2 Weeks to Replace How We Ship.
What rebuilding dawiso.com in code unlocked, and why we stopped planning a CMS. Eight weeks ago we kicked off the migration. Four weeks later we went live: 240 pages, 536 commits, 40 components, the whole site rebuilt from scratch in code. The numbers felt like the punchline. They weren't. They were the setup.
The Acceleration We Didn't Plan For
What happened in the four weeks after go-live is the actual story. And the part that matters for anyone trying to build an AI-ready marketing engine in 2026.
When we shipped the new site, our internal plan included building a "light CMS" on top: a simple admin layer for the marketing team so they wouldn't need to touch code. Reasonable plan. Standard playbook.
We never built it.
Within two weeks of go-live we noticed the marketing team had stopped asking for one. Not because they were tolerating the dev process. Because they were inside it. Each of them had spun up their own feature branch, was pushing changes, and watching their own preview URL update in minutes.
No queue. No "send it to dev." No waiting for sprint capacity.
We're a 30-person company. The marketing team is small. And within two weeks of go-live, the throughput shifted in a way none of us expected.
The Receipts
In the four weeks after go-live, the deployment repo holds 256 commits, 88 merge requests merged, 76 features shipped. 15 branches in active development today.
A note on the term: when we say "infrastructure" throughout this article, we mean the layer underneath the work: the codebase, preview branches, skills, documentation, and context that determine how fast the team can move. The migration changed the infrastructure. Everything that follows is downstream of that.
A/B Testing Moved From Roadmap to Production
We had this on our roadmap for all of 2025. It's the kind of project that sounds simple until you start it: instrumentation, traffic split, statistical significance, integrations with our campaign tooling. Every quarter we said "this is the one." Every quarter something else won the priority fight.
After the migration, we shipped it in a week. Two landing pages got A/B variants 13 days after go-live: context-layer and data-catalog. They're running now, optimizing for conversion. The thing we couldn't get to in twelve months took five working days once the infrastructure changed.
The bottleneck wasn't capacity, and it wasn't priorities. It was friction. Once we removed the friction, work that had been deferred for a year started happening in working hours.
Marketing Work Became Parallel
Anyone on the marketing team can spin up a branch, make changes across the site, and share a live preview URL with the rest of the team for review. Three people can be working on three different campaigns at the same time, each with their own preview, none of them blocking each other.
This used to require at least one developer per active campaign.
"Today the developer is the infrastructure, not a person."
Skills Replaced the CMS Layer
A CMS is a layer that lets you do specific things the developers thought to expose. We have a different layer: named skills, defined in the project, that the team triggers. A few examples:
/new-product-pagegenerates a new product page from a brief/new-componentdesigns and builds a new Astro component/new-glossary-page,/new-news-page,/new-event-pagefor typed content creation/geo-auditruns a full SEO/AI-citability check/meta-descriptionsreviews and rewrites meta descriptions/visual-qavalidates post-change visuals/deployships a preview deploy to a feature branch
Sixteen of these in the project today. They're defined once, run by anyone, and they cover what a CMS would cover plus things no CMS would touch: auditing, refactoring, structured exploration of design decisions.
A CMS would have been a system we'd have to maintain. The skills are a system we use.
Media Production Became a Pipeline
Same pattern, different domain. Images and video used to mean briefing a designer or commissioning a team. Now we run pipelines.
Our first instructional video is shipping soon: a Google generative video model for the visuals, ElevenLabs for voice-over, Claude orchestrating the whole thing. We didn't build a video team. We built a video pipeline. Imagery is heading the same way. Fewer tickets to a designer, more agents producing against our brand context.
The Pavel Test
Two months ago we hired a new frontend developer. When he interviewed, our stack was Webflow. By the time he started in April, Webflow was gone and the site was running on Astro, Tailwind, and a custom CI/CD pipeline.
He'd never worked this way. The interview had been about a job that no longer existed.
Three weeks in, he told me it was magic. Best thing that could have happened to him.
We mention this because it's the strongest evidence we have that this isn't a CEO-on-a-weekend story. The acceleration isn't reserved for whoever built the infrastructure. Anyone who walks into the infrastructure gets it.
His name is Pavel Ďuriš. Three weeks of output: a pricing page redesign, a connectors page overhaul, and an SEO/GEO sweep across our top-16 pages. Not junior commits. Team-level shipping on a stack he had never used before April.
The Economics Changed
The infrastructure underneath the marketing team changed. Everything else is downstream of that. A/B testing in a week. Parallel campaign work. A video pipeline shipping. They all came from the same change.
A year of "we want to do A/B testing" became a week of doing it.
Parallel campaigns went from "needs a dev" to "needs a branch."
A CMS, the thing we were going to build, turned out to be solving a problem we no longer had.
Pages, components, audits, meta descriptions, deploys: each of these was a discrete project six months ago. Today they're skills. Anyone runs them.
"This is the rewrite. Not the website. The math behind what a small team can ship."
What's Next
We're not announcing a CMS. We're working on something else: agents that read our marketing data and propose specific improvements. Campaign performance. Web analytics. Conversion signals. The proposals go to the website code, to the campaigns themselves, and eventually into our sales engine, so the same context flows through to the people closing.
The piece we're testing now: agents that read campaign data and propose page changes as pull requests. Real diffs. Reviewable. Mergeable. The marketing team reviews suggestions instead of writing tickets.
The harder problem underneath: the moment you let agents act on marketing and sales data, you need governance around it. Where each number came from. Which campaign it's tied to. Who owns the metric definition. What changed since yesterday. Without that, agents either hallucinate or stay too narrow to matter.
This is where we became our own customer. We build a data governance platform for a living. We're using it to expose our own marketing and sales data to the agents we're building, with lineage, ownership, and definitions intact. The agents don't read raw spreadsheets. They read a governed catalog: definitions, ownership, lineage, and the context behind every signal.
This is the same problem our enterprise customers face from the other side. AI agents are only useful when they can act on trusted context: definitions, ownership, lineage, permissions, and current signals. We're now applying that thesis to our own marketing engine.
Useful side effect for a product company: when you use your own platform for something this novel, you find what to build next. We're seeing gaps no customer has hit yet, because no customer has tried this yet. The product roadmap is being shaped by our own use case in real time.
That's the next article. We'll write it when the data justifies it.
Why Context Became the Real Foundation
A pattern we keep coming back to: the more agentic we work, the more we lean on the quality of the context we feed in. Skills are documented. Brand voice is documented. The site's design language is documented. The component library is typed. When an agent ships a new product page, it's not improvising. It's executing against a body of context the team has built up.
Better context → better agentic work → more shipping → more context to govern. We build a data governance platform for a living, and we're discovering, on ourselves, why it's the foundation we thought it was.
Eight weeks ago, we set out to replace a website. Four weeks later, it was live. Two weeks after that, we realized we had replaced something bigger: the way our marketing team ships.
FAQ
What changed after Dawiso rebuilt its website in code?
Dawiso moved from a traditional CMS-style workflow to a code-based marketing workflow built around feature branches, preview deploys, reusable skills, and documented context. Marketers and developers now work in parallel instead of waiting in a request queue.
Why did Dawiso decide not to build a CMS?
The team originally planned a light CMS for marketers. After go-live, marketers began using branches, preview URLs, and project-defined skills directly. That solved the original CMS need while enabling broader workflows such as audits, refactoring, A/B testing, and deploys, which no CMS would have covered.
How does this relate to AI and data governance?
As Dawiso added agents that read marketing and sales data, the team needed governed context: metric definitions, ownership, lineage, and trusted source data. This reflects Dawiso's broader product thesis that AI systems perform better when they operate on reliable enterprise context.
What stack does dawiso.com use now?
The rebuilt dawiso.com runs on Astro, Tailwind, and a custom CI/CD pipeline, with feature branches, preview deploys, and reusable skills supporting the marketing workflow.
