Analyst Relations · No-Code Platforms · Vendor Evaluation · Marketing Operations · Creatio.
Shashi Bellamkonda · June 14, 2026
Three years ago, Brent Leary and Paul Greenberg introduced me to Kate Rykhtyk at Creatio, and I almost filed the company under "another CRM" before the call even started.
That instinct wasn't unreasonable. I'd spent years inside customer relationship management at Network Solutions and VeriSign, and the category has a long tail of vendors competing on the same handful of features: contact records, pipelines, dashboards, integrations. One more name on that list didn't seem worth a second look.
❖
The Briefing Where "Studio" Replaced "CRM"
The actual briefing, with Jason Miller, now founder and chief executive of BrightPulse IT Consulting, a Creatio implementation partner, and Kate, didn't pitch a CRM. It pitched a studio, a no-code platform where customer relationship management is one of the applications you can assemble, not the product itself.
Three things from that conversation have stuck with me since. The platform was built to sit alongside what a company already runs, not rip it out on day one, so integration wasn't the six-month project it usually is. The technical lift was lighter than the category's reputation suggested, so time to value was measured in weeks. And instead of bending your processes to fit a SaaS provider's product definition, then waiting for your priorities to reach their roadmap, you compose the stack around how your business runs.
That third point is the one that reframed the category for me. A CRM is something you adopt. A studio is something you build with.
❖
What Nine Customers in Orlando Confirmed
I didn't get a chance to test that reframing again until this month. I met Kate in person for the first time at Info-Tech LIVE in Las Vegas, and at the end of the week sat through the second day of Creatio's No-Code Days Florida at The Ritz-Carlton Orlando, where nine customers described how they use the platform.
The verticals were wider than I expected: banking, financial services, and insurance, real estate and property management, credit unions, and field operations companies running crews instead of desks. What tied the stories together wasn't the industry. It was what "no-code" meant in practice for each of them.
No-code didn't mean the business bypassed its technology leaders. It meant business leaders could partner with their chief information officers on something that required lighter technical resourcing and moved faster, because the studio model removed the usual gate between "we need this" and "IT can get to it next quarter." Several customers described the result the same way, in plain terms. Lower costs, and less of the tech debt that piles up when every new requirement gets bolted onto an existing system instead of built cleanly into one.
The example that stayed with me came from a field operations company managing maintenance visits. Their service requests arrived as unstructured notes, the kind a scheduler used to read and interpret by hand, things like come after lunch, or I'll be back home around 9am. They built a way to mine that text and feed it directly into scheduling, cutting missed visits and the bad customer experience that follows from them.
A CRM is something you adopt. A studio is something you build with.
That's the same pattern from the original briefing, just running at scale across nine very different businesses. Less time spent waiting for a vendor's roadmap to catch up to a need, and more of the stack shaped by the people who feel the problem.
❖
The Lesson for CMOs: The next time a platform pitch includes "no-code," the question worth asking isn't whether it replaces something you already own. It's whether it changes who gets to build, and how long they wait to do it. When business teams can partner with IT to ship something in weeks instead of quarters, the savings show up twice. Once in the budget, and again in the backlog of "we'll get to that eventually" requests that quietly become tech debt.
How much of your current marketing stack exists because it fit someone else's roadmap, rather than your team's actual process? I'd love to hear where that's true for you, and where it isn't.