From Low-Code to Pro-Code: Evolving a Platform Without Leaving Users Behind

𝗧𝗵𝗲 𝘀𝗵𝗶𝗳𝘁 𝗻𝗼𝗯𝗼𝗱𝘆 𝘄𝗮𝗿𝗻𝘀 𝘆𝗼𝘂 𝗮𝗯𝗼𝘂𝘁

Every platform team that starts with low-code eventually faces the same uncomfortable question: what do you do when your most ambitious customers outgrow the thing you built for them?

At UiPath, I've spent the past few years navigating exactly this arc — evolving our Apps platform from a drag-and-drop, low-code experience into a full pro-code development platform with a TypeScript SDK, a UI widget library, hosted deployment, and most recently, a vibe code experience. All while continuing to serve the thousands of organizations already building on the low-code foundation.

This isn't a story about replacing one thing with another. It's about learning when to add a lane versus when to build a new road — and how to do it without stranding the people already driving.

𝗪𝗵𝘆 𝗹𝗼𝘄-𝗰𝗼𝗱𝗲 𝗵𝗶𝘁𝘀 𝗮 𝗰𝗲𝗶𝗹𝗶𝗻𝗴

Low-code is powerful. It democratizes app development, lowers the barrier to entry, and lets business users build real, functional applications without writing a single line of code. For many use cases — especially in automation — it's exactly the right tool.

But here's what happens as adoption grows:

𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗲𝘅𝗽𝗲𝗰𝘁𝗮𝘁𝗶𝗼𝗻𝘀 𝗰𝗵𝗮𝗻𝗴𝗲. When your app is tightly coupled to backend orchestration services, even simple apps carry startup overhead that users notice. A form that takes a few seconds to load is fine for an internal tool. It's unacceptable for a customer-facing process portal.

𝗗𝗲𝘀𝗶𝗴𝗻 𝗲𝘅𝗽𝗲𝗰𝘁𝗮𝘁𝗶𝗼𝗻𝘀 𝗰𝗵𝗮𝗻𝗴𝗲. Enterprise users now expect modern, sleek UX — fast interfaces, custom animations, responsive layouts. A fixed control library, no matter how functional, starts to feel dated when users are comparing your app to the consumer-grade software they use every day.

𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿 𝗲𝘅𝗽𝗲𝗰𝘁𝗮𝘁𝗶𝗼𝗻𝘀 𝗰𝗵𝗮𝗻𝗴𝗲. Professional front-end developers want to use their own tools, their own frameworks, their own component libraries. They want React or Angular, not a canvas editor. They want Git, CI/CD, and the full software development lifecycle — not a proprietary publish button.

None of these are failures of the low-code approach. They're signs of success. Your platform grew into a segment that demands a different kind of tooling.

𝗧𝗵𝗲 𝘁𝗲𝗺𝗽𝘁𝗮𝘁𝗶𝗼𝗻: 𝗯𝘂𝗿𝗻 𝘁𝗵𝗲 𝗯𝗼𝗮𝘁𝘀

The instinct when you see these signals is to go all-in on the new thing. Deprecate the old. Shift all investment. "Pro-code is the future" becomes the rallying cry.

We resisted that temptation, and I'm glad we did. Here's why:

Low-code still serves a massive portion of our customer base — automation engineers who need to collect data, trigger workflows, and manage processes. They don't need (or want) a TypeScript SDK. They need the drag-and-drop builder to keep working and keep improving on the things that matter to them: stability, performance, and the specific controls they've asked for.

The strategic decision wasn't low-code or pro-code. It was low-code 𝗮𝗻𝗱 pro-code, with a clear framework for when to recommend each.

𝗛𝗼𝘄 𝘄𝗲 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗯𝘂𝗶𝗹𝘁 𝘁𝗵𝗲 𝗽𝗿𝗼-𝗰𝗼𝗱𝗲 𝗽𝗮𝘁𝗵

Building a pro-code platform isn't just "let developers write code." It's a stack of deliberate investments:

𝟭. 𝗔 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁 𝗦𝗗𝗞 𝗮𝘀 𝘁𝗵𝗲 𝗳𝗼𝘂𝗻𝗱𝗮𝘁𝗶𝗼𝗻

The first and most important bet was building a public TypeScript SDK that gives developers programmatic access to UiPath platform services — orchestration, data fabric, action management, AI capabilities, and more.

This SDK is the connective tissue. Whether a developer is building a React app, an Angular dashboard, or a custom process portal, the SDK is how they talk to the platform. It's modular, so teams can pull in only what they need. And critically, it's the same SDK that our own internal teams and integrations consume — we're customer zero.

𝟮. 𝗔 𝗨𝗜 𝘄𝗶𝗱𝗴𝗲𝘁 𝗹𝗶𝗯𝗿𝗮𝗿𝘆 𝗳𝗼𝗿 𝗰𝗼𝗺𝗺𝗼𝗻 𝗽𝗮𝘁𝘁𝗲𝗿𝗻𝘀

Not every pro-code developer wants to build every component from scratch. We invested in a widget library — data tables, file uploaders, document viewers, chat interfaces — that snap into any JavaScript framework and come pre-wired to platform services.

The philosophy: give developers escape velocity. They can start with pre-built widgets for the 80% case and drop down to vanilla code for the 20% that needs to be custom. No lock-in.

𝟯. 𝗛𝗼𝘀𝘁𝗶𝗻𝗴 𝗮𝗻𝗱 𝗱𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗼𝗻 𝗽𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝗶𝗻𝗳𝗿𝗮𝘀𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲

Code without deployment is just a hobby project. We built hosting support so that pro-code apps can be deployed, published, and accessed through the same infrastructure and URLs as any other application on the platform. The goal: a developer should be able to go from npm run build to a live, authenticated, production app without leaving the ecosystem.

𝟰. 𝗩𝗶𝗯𝗲 𝗰𝗼𝗱𝗶𝗻𝗴 𝗮𝘀 𝘁𝗵𝗲 𝗻𝗲𝘅𝘁 𝗳𝗿𝗼𝗻𝘁𝗶𝗲𝗿

Here's where things get interesting. The rise of AI-assisted "vibe coding" — where developers describe what they want in natural language and AI generates the code — is collapsing the gap between low-code and pro-code.

We built a vibe code experience on top of our SDK. You describe the app you want, the AI generates real TypeScript code that uses our SDK and widgets, and you get a working application you can then hand-edit, customize, and deploy. It's not low-code. It's not traditional pro-code. It's something new — and it turns out to be a natural bridge between the two worlds.

For professional developers, it's a fast-start tool: generate the boilerplate, then take full control. For power users who aren't traditional developers, it's an on-ramp to real code without the blank-editor intimidation.

𝗧𝗵𝗲 𝗵𝗮𝗿𝗱 𝗽𝗮𝗿𝘁: 𝗰𝗼𝗲𝘅𝗶𝘀𝘁𝗲𝗻𝗰𝗲

The technical investments are the easy part to talk about. The hard part is organizational and strategic:

𝗛𝗼𝘄 𝗱𝗼 𝘆𝗼𝘂 𝗳𝘂𝗻𝗱 𝘁𝘄𝗼 𝗽𝗮𝘁𝗵𝘀 𝘀𝗶𝗺𝘂𝗹𝘁𝗮𝗻𝗲𝗼𝘂𝘀𝗹𝘆? You can't invest equally in everything. We made a deliberate choice: continue addressing committed customer needs and critical stability items on the low-code side, while shifting new feature investment toward pro-code. This isn't abandonment — it's maturation. Low-code gets reliability and performance investment. Pro-code gets feature velocity.

𝗛𝗼𝘄 𝗱𝗼 𝘆𝗼𝘂 𝗴𝘂𝗶𝗱𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀 𝘁𝗼 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝗽𝗮𝘁𝗵? Not every customer should be on pro-code. If you have automation engineers (not front-end developers), low-code is still the right answer. If you have front-end developers and need custom UX, performance, and full SDLC — pro-code will deliver a better experience. We had to build this decision framework explicitly, not let customers stumble into the wrong one.

𝗪𝗵𝗮𝘁 𝗜'𝘃𝗲 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝗹𝗲𝗮𝗱𝗶𝗻𝗴 𝘁𝗵𝗶𝘀 𝘁𝗿𝗮𝗻𝘀𝗶𝘁𝗶𝗼𝗻

𝗦𝘁𝗮𝗿𝘁 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝗦𝗗𝗞, 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗨𝗜. If your SDK is solid, the UI experiences — whether low-code canvas, pro-code IDE, or vibe code AI — are just different front doors to the same platform. We invested in the SDK before building the flashy demos, and it paid off.

𝗕𝗲 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿 𝘇𝗲𝗿𝗼. Our own internal teams — the ones building process portals, vertical solutions, and pre-sales demos — are the first consumers of the pro-code SDK and widgets. Every friction point they hit, every missing API, every clunky developer experience gets fixed before external customers encounter it. Dogfooding isn't optional.

𝗗𝗼𝗻'𝘁 𝗰𝗼𝗻𝗳𝗹𝗮𝘁𝗲 "𝗼𝗹𝗱" 𝘄𝗶𝘁𝗵 "𝘄𝗿𝗼𝗻𝗴." Low-code isn't legacy. It's a different tool for a different user. The moment you frame the evolution as "the old way vs. the new way," you alienate the customers and teams who built their success on the existing platform. Language matters.

𝗟𝗲𝘁 𝘁𝗵𝗲 𝗺𝗮𝗿𝗸𝗲𝘁 𝘁𝗲𝗹𝗹 𝘆𝗼𝘂 𝘄𝗵𝗲𝗻 𝘁𝗼 𝗮𝗰𝗰𝗲𝗹𝗲𝗿𝗮𝘁𝗲. We could have invested in pro-code years earlier. The market wasn't ready. The convergence of AI-generated code, the maturation of TypeScript as a universal language, and the explosion of agentic platforms that need embeddable UI components — that's what made this the right time.

𝗪𝗵𝗲𝗿𝗲 𝘁𝗵𝗶𝘀 𝗶𝘀 𝗵𝗲𝗮𝗱𝗶𝗻𝗴

The lines between low-code, pro-code, and vibe code are blurring. In a few years, I don't think users will care about the distinction. They'll describe what they want, get working code, customize it if they choose to, and deploy it — all within a platform that handles the hard parts (authentication, hosting, service integration, data access) invisibly.

The platforms that win will be the ones that didn't force their users to pick a lane too early. That invested in a strong service layer (the SDK) and built multiple on-ramps (drag-and-drop, TypeScript, natural language) on top of it.

The future of enterprise app development isn't low-code or pro-code. It's the platform underneath that makes both possible — and makes the distinction irrelevant.

—

I lead the engineering teams building UiPath's pro-code app platform and collaboration integrations. If you're navigating a similar low-code-to-pro-code evolution, I'd love to compare notes.

#SoftwareEngineering #LowCode #ProCode #VibeCoding #TypeScript #PlatformEngineering #UiPath #EngineeringLeadership #AgenticAI