A language, AI-powered IDE, and serverless runtime for spreadsheet-style logic

Every engineer has tried to save an ops team from spreadsheet hell. We show them Python. We build them dashboards. We promise a better way. And they always, always go back to spreadsheets.

For the past seven years, I’ve been obsessed with solving this problem. And it’s been so much harder than I expected.

There’s a hidden crisis in every company

Watch any operations or finance team for a day and you'll see some scary stuff:

• Copy-pasting from emails into Excel
• Using cmd + f to one-by-one go through a long list of find/replace rules
• VLOOKUPs referencing random Google Sheets that break when someone renames a column
• Eyeballing PDFs to manually enter data
• Hardcoding values when systems don't talk to each other
• Redoing everything when an exec questions why a number doesn't match

This is how critical business processes like inventory reconciliation, invoice auditing, and GL mapping actually work at most companies.

But this isn't incompetence. These processes change too fast and handle too many messy data edge cases to be solved with code. The people doing this work have deep domain knowledge and know exactly what needs to happen. They just lack proper tools.

We tried to solve it differently than traditional solutions

RPA tools break when UIs change. No-code platforms hit walls with real-world data complexity. BI tools assume your data is already clean.

These existing tools just weren’t designed to solve these kind of problems.

So we set out with a fundamentally different approach: an entire engineering stack-equivalent designed for how business teams actually think about data.

• ‍A domain-specific language that operates on data the way someone thinks in spreadsheets, not SQL or Python. When an ops person says "match these two lists but ignore blanks and typos," it just works as expected.‍
• A visual IDE with live debugging where every transformation shows instant previews. Users see exactly what's happening to their data at each step without having to wait until the end to “run and pray”‍
• A schema-less calculation engine that handles the reality of business data—CSVs that gain columns overnight, five different date formats in one file, random strings where numbers should be.‍
• Production-grade infrastructure including simple abstractions for statefulness, serverless deployment, inbound email triggering, comprehensive logging, and exception handling that actually helps non-technical users fix what went wrong.

But the technology just wasn’t there yet

Building all of this got us partway there. We managed to close some impressive logos I was proud of, but adoption was still limited to power users who could translate business logic into visual flows.

Seven years in, we'd built a domain specific language, IDE, and serverless runtime. And most people were still going back to spreadsheets.

Then this year, LLMs reached a tipping point. And we finally added two features we should have had all along:

• ‍An AI agent that actually understands operations. It's trained on thousands of real workflows and can build with you or for you. Ask it to "reconcile these invoices but flag anything over 5% variance" and it knows exactly what you mean.‍
• Dynamic code generation that adapts. Instead of brittle scripts, Parabola generates fresh code on the fly that updates when your data shape changes. The code is visible, auditable, and modifiable—no black boxes.

In hindsight, we were incredibly naive to try to tackle this problem before 2025-grade LLMs. I could justify it to myself that AI only works when it has the right foundation. Without our domain-specific language and tooling, this would just be another chatbot that generates broken Python.

But the reality is it doesn’t matter if it was well planned or just good timing. Because regardless, ops teams are now prompting their way to production-grade automations.

Getting an AI agent to actually understand ops problems

LLMs in 2025 are increasingly great at reasoning through problems step by step, and surprisingly good at generating code to solve those problems. They have massive amounts of code to train on.

There’s far less available training data for ops and finance workflows, because so much lives in people’s heads or in private docs.

So we had to build a lot of new tools for our AI agent to use that give it the ability to

• ‍Manipulate Parabola flows by adding/removing steps, adding/removing connections, updating settings, etc.‍
• Look up info in our public facing docs, internal docs, and templates‍
• Get schema information for each step type and compare proposed changes with preconfigured examples‍
• Access context the user wants to share like error messages and selections‍
• Communicate back/forth with the user in structured ways

And to make these tools work well, we had to create a lot of carefully tuned content

• ‍Partial Parabola flows demonstrating important patterns and efficient ways of solving hard problems‍
• End-to-end templates for our most popular use cases‍
• Schemas and sample data sets for all of our integrations and transforms‍
• A compilation of the internal docs, looms, and siloed knowledge our cx teams use internally into parseable docs‍
• Examples of how to know when a user is asking a question about a use case vs. asking to actually make a change

[happy to share the technical details if anyone’s curious, just DM me]

Technical teams still need to help upskill their business teams

Ops and finance teams need to work like engineering teams. With repeatability, scale, and an increasing adoption of AI. I’m hopeful Parabola can be a big part of the solution.

But they need help from their technical counterparts to get there. They need encouragement and guidance on what problems are worth tackling first. It might feel like taking on extra work, but it’s SO worth it on the other side.

Fewer “quick python scripts”, more auditable processes, and the ability to scale without hiring are all clear ROI. But what gets me out of bed in the morning is the raw excitement ops and finance people have the first time they build something real that solves a problem they’ve been handling manually for years.

I’d love to hear what you and your teams think. You can try Parabola here, or see some example flows.

‍