Four tools.
Not one good decision.
The client ran their entire marketing and sales operation on a set of tools that were never meant to work together: Meta Ads in one place, Google Ads in another, a CRM living in a Google Drive spreadsheet, and reports exported to Excel every week.
The visible problem was lost time. The real problem was subtler: investment decisions being made on data that always arrived late. When it takes you two days to consolidate last week's report, you are already three days behind.
"The obvious move would be to connect APIs and assemble a generic panel. The right move was to understand how the team made decisions and build something that follows that logic."
The initial brief asked for a "marketing dashboard". After three hours of conversation, it became clear that what they needed was not a panel. It was a single source of truth for the whole operation.
Why build
from scratch, not customize.
The first question any honest dev asks on this kind of project: wouldn't Notion + Zapier + a good Google Data Studio template cover this?
Sometimes it does. Not here. The reasons:
- 01The client had their own naming for funnel stages. Off-the-shelf tools don't bend to that without hacks that break the moment you update your plan.
- 02The integration between CRM and paid media needed specific business logic: attribution, stage rules, alerts based on relative performance, not absolute.
- 03The AI agent would not be possible on top of a third-party tool. It needed direct access to the data, not an export layer.
- 04Long-term cost: stacked SaaS tools add up fast. A custom build carries infrastructure cost, not per-seat license cost.
Chosen stack: React + TypeScript + Vite on the front end, direct integration with the Meta Ads and Google Ads APIs, a dedicated database for the CRM, and Claude as the engine behind the AI agent.
Product design,
not dashboard design.
Most dashboards fail for a reason that is not technical: they are built as mirrors of a database, not as decision tools. You see the data organized the way the system stores it, not the way you use it to think.
Before opening Figma, I mapped the team's real decision-making flow. What question did they ask first when they opened their computer in the morning? How often did they check each type of data? When did a number need context from another module to make sense?
Three principles guided the design:
- AInformation hierarchy by frequency of use, not by perceived importance. What the team checked every morning went to the top. What they checked once a week sat two clicks away.
- BCross-context visible without navigation. When you are looking at media performance, the sales funnel for that same period appears collapsed beside it. You expand it if you need to, without switching screens.
- CThe business's terms, not the tool's. The CRM didn't call a "Lead" a lead: it used the name the team used internally. Sounds obvious, but most tools force you to learn their naming instead.
Process insight
I spent the first two weeks without writing a line of code. Just mapping flows, asking questions and sketching wireframes on paper. That was the decision that saved the most time in the end. Every hour of discovery you skip becomes two days of refactoring later.
AI that answers,
not AI that adds noise.
The AI agent was the most delicate module, not because of the technical implementation, but because of scope definition. The wrong question is "what can the AI do?". The right question is "which specific task does the user do manually today that AI handles better than any interface?"
For ADASH, the answer was clear: interpreting weekly reports. Every Friday, someone spent 45 minutes staring at numbers, trying to articulate what they meant in plain language for the sales team. That is exactly what an LLM does well.
The agent has direct access to the account's context: media metrics, funnel stages, campaign history, and it answers questions in natural language. It is not a generic chatbot. It knows the business.
Three rules guided the implementation:
- 01The agent only talks about what it knows. No speculation. If the data is not in its context, it says it doesn't have the information.
- 02Every answer comes with its source. The user can check the raw number if they want. Trust is built with transparency, not with fluent answers.
- 03The agent doesn't make decisions. It presents context and points out implications. The decision stays with the human.
What happened
each week.
Discovery and architecture
Flow mapping, interviews with the team, module definition, paper wireframes. Stack and data structure decisions. Client approval before a single line of code.
Core modules: Performance + CRM + Content
Meta Ads and Google Ads integration. Real-time performance dashboard. Kanban CRM with a custom pipeline. Editorial calendar per channel. Design system implemented in code in parallel.
QG Agent + Reports + Deploy
AI agent implementation, prompt calibration with real data. PDF generator with the client's identity. Usage sessions with the team, UX adjustments, production deploy and handoff.
The mistakes
worth documenting.
Every project has at least one decision you would make differently the second time. On ADASH there were two:
I started the reports module too early
I began implementing the PDF generator in week 4, before the final design of the other modules had settled. Result: I had to refactor part of the data structure when I changed the dashboard layout in week 5. Not critical, but it cost half a day that wasn't in the plan.
Lesson: output modules (reports, exports, notifications) should be the last ones implemented, because they depend on how the data is structured in the core modules.
I underestimated the agent's tuning time
Implementing the AI agent took two days on the technical side. Getting it to behave the right way, answer in the right tone, not hallucinate, know when to say "I don't know", took another week of prompt adjustments and tests with real data.
Lesson: on LLM projects, separate "implementation" from "calibration". They are distinct phases. Calibration is never in the initial scope and only fits the deadline if you reserve time for it explicitly.
On the deadline
3 weeks is tight for a SaaS with 5 modules and integrated AI. It was possible because there is no management layer: the person who designed it implemented it, the person who implemented it tested it, the person who tested it deployed it. No alignment meetings between design and dev, no manager sign-off, no sprint planning that doubles the time without doubling the output.
What the team
has today.
ADASH has been in production for months. The team uses all five modules daily. Weekly analysis time went from hours to under 20 minutes. The AI agent gets consulted before every performance meeting.
But the most important result is not in any of those metrics: they stopped using spreadsheets. When a team permanently migrates from an old workflow to a new tool, without being forced to, it means the tool is solving a real problem the right way.
That is the test I use to judge whether a digital product worked.