As a Domo consultant, I always push customers to stretch the last mile — what do you want to DO with your data? At this point data collection, transformation, presentation, and even distribution has been trivialized, so how do you transform it into an inherently valuable asset — a service, a product?
I hear customers lament that Domo's consumption model makes it too expensive and I can't help but think they are leaving money on the table. Surely they must be missing an opportunity to do something cool with data — or maybe they're just missing part of Domo's value proposition. To be fair, I think Domo aren't great at describing what makes their platform so good, but I low-key stumbled onto a fair chunk of value in the months following the most recent Domopalooza when I stopped using their platform in March.
Part of Domo's remarkable narrative has always been the huge things small teams can accomplish when backed by the platform. Recent platform extensions — CodeEngine, Workflows, Triggers, and the AI service layer — have made Domo a competent AI orchestration layer, promising exponential 🤮 acceleration when paired with agentic coders like Claude for small teams prototyping, deploying and iterating on data products.
But if you've worked with Domo, you also know, it's never the best at anything. The errors can be frustratingly opaque. And it's definitely a club where IYKYK but otherwise you don't know.
I have a Claude subscription in 2026. Do I really need Domo to deliver data products that delight? Can I jump on the 'no SaaS subscriptions' bandwagon? I thought I would put Domo down and try building without it.
What It Takes
At the height (hopefully we hit the height) of the RAM crunch, I decided to buy my own GPUs so I could do my own inference and skip paying my Claude subscription. Buying the hardware was pretty easy. Getting Ollama to reply to "hello world" was cake. Setting up a harness to replace Claude was out of the question — the tokens per minute, quality of LLM responses, and context window size on a 24GB GPU just wasn't cutting it. Don't come at me — I know SOMEBODY took the time to figure out how to make it work. But that's not why I was here. I wanted to prove I could build powerful data interactions without Domo's infrastructure.
I started with everyone's first project — an always-on RAG-powered Slackbot for the Domo User Group. I'd built this as a hackathon project two years ago with Domo's FileSets tooling. This time I wanted to do it without Domo on an always-on VPS. There are hundreds of YouTube tutorials on a locally hosted 'hello-world' chatbot, but few people go through the intricacies of safely setting up a personally hosted, always-on agent with local inference that doesn't give the world a "free" Claude Code subscription. I hosted my Slackbot in a Docker container on a Hostinger VPS, with Twingate tunnels to my personal GPU server for private inference. Between Claude and me, it's amazing how far we've come in 5 months — but back in March, when things broke, I understood none very little of it.
What I did learn off the jump: Domo includes serverless functions, workflow automation, MongoDB, vector database, Python workflows, data hosting, and user management — without worrying about hosting, tunneling, database backup, or server software updates. Sure, Domo goes down sometimes, but I guarantee you my webserver went down more often. And all the time I spent learning about self-hosting was not even close to 'building something new and cool' — I was just trying to recreate a hackathon project I'd completed two years ago.
Do you see a trend to my story?
SaaS platforms handle a lot of the setup shenanigans that we take for granted. Sure, if I had a fleet of engineers in networking, infosec, and devops, the previous work would have been trivial. But I'm just a pretend-gineer armed with a Claude Code subscription.
In early May I launched my always-on chatbot. You can chat to EmmaBot on Slack and ask her questions about Domo — she's generally more knowledgeable than me. She has an internal knowledge store built on Domo's public documentation and developer documentation, plus access to the source code behind my Domo Python SDK and blog. She's not ALWAYS right, but her Letta.ai harness keeps her learning and building memories.
Under the covers, EmmaBot stores data in MongoDB + Atlas (vector embeddings) + Neo4j (graph relationships). But I hit another wall. I wanted a private assistant too, so I spent weeks making sure Alix's knowledge store wasn't co-mingling data with EmmaBot's. I wanted multi-user, multi-tenant infrastructure so all community members could use EmmaBot as an executive assistant — which meant figuring out multi-user authentication, registration, and entitlement management. Not just for Slack, but for any platform where users have data stored. I had to re-invent Domo's PDP — the row-level security everyone SHOULD use but never does. This time it really matters, because EmmaBot can check my email and manage Google Docs.
But again, governance and security is invisible work. NOBODY CARES about security unless there's a leak! Three months and hundreds of hours in, we still have stuff you get out of the box with pinecone.io and viktor.com. At this point, my chatbot isn't even as good as Viktor — it's just "a brain in a pickle jar." No skills, no integrations, no ability to take action.
I wanted to give my agent the ability to do work for me. The obvious first workflow was a YouTube researcher — download transcripts, push them into EmmaBot's knowledge store, extract summaries, deep-research embedded links, and tell me something new. That was swell, except I hate reading Markdown, so I needed to write a Google Docs integration so I could see my articles with beautiful formatting.
Maybe this all sounds easy, but in 5 months I've worn 3 new hats. First dev/ops and infosec, then software and platform engineering, and now — finally — AI Engineering. It's no joke. When you build your own SaaS, you low-key have to do everything. For five months, I've been raking myself over the coals to build a stack that does what Domo has built over 15+ years. Sure, some of my motivation has been uncertainty about the future of Domo, a desire to not be a one-trick-pony, and a non-trivial amount of hubris — "surely I can build it better." I wanted to see what it takes to ditch Domo. And I'll tell you — it takes more time than you think.
I'm not so naive to think I built anything better than a team of engineers would have. I'm by no means an expert in any of the fields I dabbled in — I'm just a guy trying to learn at the speed of Claude. I'd be lying to say I properly reviewed the PRs Claude was pushing, let alone the code. But at some point, if you're a small team you pick your battles. Where do you want to deliver value? On bulletproof infrastructure, or at that last mile of building cool products? Every day I spend hours on invisible infrastructure stuff is time I can't spend writing blog posts or making YouTube videos. Because THAT is where the value is, and honestly, re-inventing Domo is not it.
I think when companies balk at there being "better" or "cheaper" options than XYZ platform, it's coming from engineers and consultants who feel this compulsion to do it better than the platform. And I get it — I felt it too. But five months in, I can tell you that the "better" and "cheaper" parts are about license costs and feature lists. Nobody counts the time.
The Things You Take for Granted
Here's what I didn't appreciate until I didn't have it: Domo does two things that I miss every single day.
You Can't Tune What You Can't See
I have workflows running that do stuff. But it always feels like a hassle to figure out "what got done" or "why isn't the output better." In Domo, every action by every user and every agent is logged. Automatically. No SDK to install, no exporter to configure, no per-trace billing. You run a workflow, and you have receipts.
Elliott Leonard published a video showing trigger-based agents in Domo — an agent that runs when an error gets recorded, diagnoses the problem, files a support ticket, and emails the account team. After 7 runs, he can tell Claude "you messed up on step 3 three times in a row, update your prompt." He has receipts. Built into the workflow. No extra tool required.
In my stack? I'd need to install LangSmith or Langfuse, wire up SDKs, configure exporters, manage API keys, and pay per trace. Every time I swap frameworks or add a new agent, I re-instrument.
A log of what your agent did isn't icing on the cake. It's arguably more important than getting a good result. You can't tune what you can't see.
The Part I Skipped
I shouldn't tell you this, but I use the same security tokens for everything. Meaning in my automations it can be hard to tell why an email was sent, or which dataset an agent accessed, or whether it should have.
In Domo, when an agent runs, it runs using your credentials. Those credentials pass through PDP — Personal Data Permissions, Domo's row-level security — auto-magically. The agent can't access data you shouldn't see. It's both security and governance at the same time, and you don't have to build it or maintain it. It's there.
In my stack? My agents use the same creds for everything, making observability challenging. Heck, NGL there's a reason all my GitHub repos are private — if I had a dollar for each secret committed into GitHub… I'd be able to pay for a Claude subscription. User, secret, and access control management is arguably the most important layer in the infrastructure cake, but it's the hardest. And when you roll your own — bad design isn't a question of IF you'll leak data so much as when.
I said earlier that I wouldn't claim what I've built is secure. I'm sure Fable wouldn't blink an eye cracking into all my attempts. But you have to pick where you're getting value. For a small team, you can focus on the infrastructure or you can get to the cool stuff that moves the needle — the chatbots, workflows, and knowledge store. Invest in platforms like Domo or invest in engineering teams. Or both!
The Last Mile
I'm not going to pretend Domo is perfect. It has a ton of shortcomings. Snowflake is a better warehouse. Tableau has deeper support for Analytics communities. LangSmith has richer agent tracing. You could probably build a better individual tool stack. But it'll cost you time and money on 'invisible' work. In hindsight I wouldn't trade the journey.
I appreciate the SaaS industry a lot more. As I continue to extend automations, services and capabilities in Domo as well as my self-hosted server, I am better able to spot concessions Domo has made, value Domo has delivered, and have a broader appreciation for infrastructure I might take for granted.
At this point, I wouldn't qualify myself as an expert in anything. AI is humbling like that. You can be a generalist who knows a little bit about a lot. You rapidly discover through adversarial reviews that strong held opinions are never as air tight as you thought they were. And Claude reminds you on the daily how much you don't know — all you can do is ask more questions, do more learning, and appreciate the work of the engineers whose shoulders you stand on.
Because the last mile has never been so real to me. In BI, we always talked about "what do you DO with the data?" — can we get the data, shape the data, present the data SO THAT we can do something useful with it. Now my appreciation is deeper, because so much infrastructure, security, and governance went into the data collation process before you even get to the last mile. Now, in addition to doing something useful with it, we want to do something useful that is also safe, governed, and secure.
I wanted to see what it takes. Now I know. It takes more time than you think — and it's worth every hour of it.
