The Spark: Why We Decided to Build Our Own Low-Code Platform

The blue glow of Maya’s monitor cut through the dim light of the Nexus engineering floor at 8:17 PM on a Monday, the only sound besides the hum of server racks the rhythmic clack of her mechanical keyboard and the insistent ping of Slack notifications from the customer success team. She’d been hunched over the same file for three hours, tweaking the API payload for a third-party compliance check that was the final, non-negotiable step in the onboarding flow for Meridian Health, a $2 million annual healthcare SaaS client. The logic she was writing—retry failed requests three times with exponential backoff, scrub patient identifiers from payloads before sending them to ComplyAdvantage’s API, log every request to an immutable audit trail for HIPAA compliance—was identical to the code she’d written for three other healthcare clients in the last six months. The only differences were the API keys, the names of the custom data fields, and the exact error messages the clients wanted to show their end users. She’d copied the core structure from a previous client’s repo, pasted it into the new project, and was now doing the tedious work of renaming variables and adjusting edge cases that should have been automated.

A Slack message from Alex, the team’s junior engineer, popped up in the corner of her screen, breaking her focus: *“Maya, I pulled the Jira time logs for last quarter’s onboarding flows. You’re not gonna believe the number of hours we wasted on重复 work. 127. That’s almost a full month of one person’s time.”*

Maya minimized her code editor and opened the spreadsheet Alex had shared. The numbers were sickeningly clear: the team had built 14 custom onboarding flows for new enterprise clients last quarter, each taking an average of 16 hours from kickoff to launch. Of those 16 hours, only 6 were spent building logic unique to the client’s specific industry, compliance requirements, or existing tech stack. The other 10 were spent rebuilding the same base scaffolding: multi-step form validation, API connection error handling, role-based access controls for the flow’s end users, and audit logging for compliance. 14 flows times 10 hours of重复 work was 140 hours, minus 13 hours for three niche clients with fully custom requirements that couldn’t reuse any base logic, landed them at 127 hours of pure waste.

She did the mental math fast, the same calculation she’d run a dozen times in the last month: that 127 hours was equivalent to 16 full workdays, or nearly a month of a single engineer’s time. That engineer could have been building the real-time analytics module the product team had been begging for since Q1, a feature that would have let clients see live usage data for their teams and was projected to increase annual renewal rates by 12%. Instead, the feature had been pushed from Q3 to Q4, then to Q1 of the next year, because every time the engineering team thought they had bandwidth to start, a new client would sign and demand a custom onboarding flow that required immediate attention.

The problem wasn’t that the team was inefficient. It was that every onboarding flow was a snowflake: nearly identical in structure, but with just enough small differences that they couldn’t reuse code across clients without spending hours refactoring. They’d tried building a shared library of onboarding components a year prior, but it had been abandoned after three months because every new client had a requirement that didn’t fit the existing components, and updating the library for every new use case took longer than just building the flow from scratch. The only other option was buying an off-the-shelf low-code platform, but the team’s three-week deep dive into the market had left them frustrated and convinced that no existing tool could meet their needs without costing a fortune or locking them into a vendor’s constraints.

📌 *Sidebar: The 2024 Low-Code Tool Landscape for Enterprise SaaS Teams* For context, the team evaluated 8 tools across three categories during their research, scoring each on a 1-5 scale for 5 key criteria relevant to Nexus’s use case: | Tool Category | Examples | Strengths | Critical Gaps for Nexus | |---------------|----------|-----------|--------------------------| | Open-source low-code | NocoBase, Budibase, ToolJet | Free to self-host, full code access | No extensible plugin system for custom logic; runtime performance caps at ~1,000 concurrent flows; no built-in HIPAA compliance tools | | Enterprise commercial | OutSystems, Mendix, Betty Blocks | Full feature sets, enterprise support | $50k+/seat/year licensing; vendor lock-in prevents custom runtime modifications; no support for client-specific data residency requirements | | Internal tool builders | Retool, Appsmith | Fast internal admin tool development | No support for external customer-facing flows; weak role-based permission systems for end users; no workflow orchestration for multi-step processes |

The numbers were damning. The cheapest commercial option that met their basic feature needs would cost $52,000 per user per year, and they needed 13 seats (8 engineers, 5 customer success staff) for a total annual cost of $676,000. That was more than double the $120,000 it would cost to build their own platform in 18 months, with three engineers dedicated to the project full-time. And even if they paid that cost, they’d still be stuck with the tool’s limitations: no way to add their proprietary customer health scoring logic as a native workflow step, no way to store client data in their own AWS GovCloud region for HIPAA compliance, and no way to let customer success teams edit flows for their clients without giving them access to the tool’s full admin panel.

By the time Maya closed her laptop and walked out of the office that night, she had a one-page proposal drafted in her head. She spent the next two days refining it, adding cost calculations, risk assessments, and a timeline that balanced the leadership team’s demand for fast ROI with the engineering team’s need for realistic scope. The core of the proposal was three non-negotiable requirements for the internal platform, which they’d tentatively named the Nexus Internal Low-Code Platform (NILP):

1. A visual drag-and-drop modeling tool usable by non-technical customer success teams: No coding required, no engineering tickets needed to edit or launch new flows. This was non-negotiable because the entire point of the platform was to eliminate the engineering bottleneck for onboarding flow changes. If customer success teams still needed to wait for engineering to build or edit flows, the platform would just be a fancy new way to do the same old work.

2. A plugin ecosystem that lets engineering teams add custom logic and data connectors without modifying core platform code: Plugins had to be hot-swappable, with no platform downtime required to install or update them, and fully isolated from the core codebase to prevent bugs in one plugin from breaking the entire platform. This was non-negotiable because Nexus’s clients spanned healthcare, finance, and retail, each with unique compliance requirements and third-party system integrations. If every new custom logic required a core platform change, the platform would become a maintenance nightmare within a year, with every new client request forcing a full regression test of the entire system.

3. A runtime engine capable of executing 10,000+ concurrent flows with sub-100ms latency for critical steps: The engine had to be built to scale to 10x their current client base within three years, with no performance degradation as flow volume grew. Critical steps like payment validation, compliance checks, and user authentication had to complete in under 100ms to avoid user frustration and support tickets. This was non-negotiable because slow onboarding flows were directly tied to lower customer satisfaction scores: in the last quarter, three clients had nearly canceled their contracts