Almost three years into building SaaS for enterprises at Carboledger, the hardest part was never the product itself. It was the layer around it: industry-specific regulation, understanding how people actually work within real constraints, and building something that scales without losing the ability to fit custom requirements.
Every client is genuinely different. Workflows shift with geography, hierarchy, and company structure, and a company operating across continents behaves nothing like one operating in a single region. On top of that, whatever you build has to slot into their existing systems, talk to their ERPs, ingest data from wherever it already lives, without adding extra work. Add external stakeholders into the mix and trust becomes its own problem, layered on top of long procurement cycles and custom pricing.
Gaining domain knowledge
Copying a user's workflow and automating it isn't enough. You need the context behind it, the regulations, restrictions, and dependencies that can quietly break a feature you thought was solid.
We once built a feature based on one client's stated requirements, and it made complete sense in their context. Validating it with other prospective clients showed the gap: that client operated under different regional compliance rules, and the same feature didn't generalize. Even the act of 'copying' a workflow is harder than it sounds, because users rarely describe their process as a clean sequence. It comes out in fragments, like an improv sketch, and you have to piece it together yourself.
Building something that scales
No single solution fits every enterprise client. The right sequence is solving the core use case first, validating it through demos and pilots to check for real product-market fit, and only then investing in modularity.
We've had plenty of cases where a feature one client asked for was irrelevant to everyone else. Rather than hardcoding it in, we built a centralized configuration layer so features can be toggled per client and tied to customized pricing. The actual challenge is balancing that flexibility against the risk of quietly breaking the product for clients who never asked for the feature in the first place.
Fitting into existing workflows
Enterprises, especially in supply chain and sustainability, already track enormous volumes of data: inbounds, outbounds, inventory, allocations, usually spread across SAP, Salesforce, or other internal systems. Expecting them to duplicate that data entry across yet another tool is a non-starter, and integrations or bulk upload support come up in nearly every demo as one of the first questions.
It goes further than the initial integration too: who on their internal team gets access, what permissions do they have, can they export for their own reporting, how do they share it with stakeholders outside the platform. Getting this wrong adds friction instead of removing it, which defeats the purpose of the tool.
External stakeholders and trust
We built a data exchange tool where third-party stakeholders share data directly with our enterprise clients. For those external users, security is the first and loudest concern: is the platform safe, who can see their data, how is it used. Compliance certifications like GDPR, SOC 2, or ISO 27001 matter to IT teams reviewing the vendor, but the people actually uploading data care about something more direct, visibility into what happens to it and where it goes. Nobody wants to feel like their data disappeared into a black box, and building that transparency at the product level, not just in a policy document, takes real design work.
Standardizing data with AI
A meaningful chunk of enterprise data arrives unstructured, PDFs from third-party suppliers, each organization formatting reports differently. Extracting anything useful from that used to mean manual effort with gaps that never fully closed. AI-based document processing has closed a lot of that gap, making extraction and mapping far less painful, though not fully deterministic. Human oversight is still necessary. Handling this kind of data by hand is high effort and low reward, mostly repetitive rather than genuinely difficult, which is exactly the kind of work where AI creates the most real value.
Closing thought
Building SaaS for enterprises means going past features into the domain itself: the regulations, the workflows, the mental models of the people actually using it. Every client's structure and constraints are genuinely their own. The hard problem was never building the product. It was building something that fits into all of that without breaking under the weight of it.