10 years building internal tools, and the SaaS stack is still a nightmare
We built a SaaS used by hundreds of companies (sometimes with thousands of employees per account) to manage their internal operations.
We ate our own dog food from day one. If anyone was supposed to get this right, it was us. And yet… our SaaS stack ended up being a mess.
We had a powerful admin panel from day one. But around it? Chaos.
Each team had their own tools: - Sales lived in HubSpot - Support used Intercom - Docs were spread across Google Drive, Notion, and Slite - Comms happened in Slack, of course - BI ran on Metabase connected to a fragile warehouse - Automation was duct-taped with n8n - Data modeling happened in dbt, pulling from a dozen disconnected SaaS tools
But context was scattered. Workflows broke easily. APIs failed silently. Engineers debugged glue instead of shipping. The SaaS bill was huge. Onboarding/Offboarding took hours. Invoices reconciliation too. We used dozens of tools. Many forgotten, none truly integrated.
You can’t scale on a stack you don’t control. Even with the best internal tooling, if the foundation is fragmented, it will break.
At some point, engineers lost control of the stack. And I think it’s time to get it back and rebuild systems that are coherent by design.
So I’ve decided to go back to first principles. I’m bootstrapping a new company to rethink how the SaaS stack should be architected from the ground up. Not patched, rebuilt. A rethink of the foundation itself.
If you’ve hit the same wall. Too many tools, not enough truth. I’d love to hear how you approached it. Where did you start? What tradeoffs did you make? And what would you do differently, if you had to rebuild your internal stack from scratch? What should a modern foundation for SaaS systems look like?
No comments yet