Back to Case Studies
Nisto logo

Why Nisto Left Flatfile for Dromo: The CTO's Full Account

Nisto did not leave Flatfile over speed, support, or price. They left because they could no longer tell why imports were failing. Stale docs, an architecture that had stopped changing, and too little developer surface to debug against had removed the team's ability to reason about its own system, and they moved to Dromo.

Albert Aznavour on October 26, 2026 • 12 min read
Nisto case study cover
Nisto case study cover

Hundreds

of imports a month

2

schemas in production

1

feature request since go live

6

months from first conversation to decision

About Nisto

Nisto builds technology and infrastructure for credible social impact reporting, including Indigenous procurement reporting, turning raw operational and accounting data into standardized, verified statements.

Nisto, which builds social impact reporting infrastructure, left Flatfile for Dromo in early 2026. Its CTO says the reason was not price, support, or an outage: the team could no longer tell why imports failed, because documentation had gone stale and too little of the platform was exposed to debug. The migration reused most of the Flatfile code, and Nisto now runs hundreds of imports a month on two schemas.

CompanyNisto, technology and infrastructure for credible social impact reporting
IndustryImpact and supply chain reporting, including Indigenous procurement reporting
InterviewedCraig Schlegelmilch, Chief Technology Officer
Previous vendorFlatfile, now Obvious
Running todayHundreds of imports a month on 2 schemas, live since March to April 2026

Nisto did not leave over speed, support, or price. They left because they could no longer tell why imports were failing.

Flatfile now trades as Obvious, and its homepage no longer mentions an importer. Nisto left because when an import failed, nobody could establish why. Stale docs, an architecture that had stopped changing, and too little developer surface to debug against had removed the team's ability to reason about its own system, and they moved to Dromo. A vendor you cannot debug is a vendor you cannot trust.

"We just couldn't trust it because we didn't know why things didn't work. Even if it was our fault, we still didn't know, and that was the problem. It's a really horrible position to be in."

Craig Schlegelmilch, Chief Technology Officer, Nisto

Did Nisto leave Flatfile over price or support?

No. The invoice and the support queue were both fine, and Nisto left because failed imports could not be diagnosed.

Three explanations are the ones people reach for. None of them is what happened.

Not support. Craig Schlegelmilch, Nisto's Chief Technology Officer, called it "not terrible." By the time support came up, the team had already stopped expecting it to be the fix.

Not the bill. No invoice ever broke the budget. What hung over the contract was a repricing Flatfile had signaled but never dated, on terms it never specified, which is a planning problem rather than a cost one.

Not a crisis. There was no outage and no bad week that forced the decision. Six months passed between the first conversation with Dromo and the decision to move.

About Nisto

Nisto builds technology and infrastructure for credible social impact reporting, including Indigenous procurement reporting. Customers submit raw operational and accounting data and get back a standardized, verified statement. Nisto's own site describes linking every supplier in a project's ecosystem into a contiguous supply chain, capturing verified data at each step down to Tier 3 vendors.

That is why the import is not a peripheral feature. The statement is the product, and its credibility rests entirely on the data going in. An import layer nobody can see inside is not a tooling annoyance. It is a risk to the thing the company sells.

Why could nobody tell what was failing?

Because too little of the platform was exposed to look at: the parts Nisto needed visibility into were not the parts the platform surfaced, a failure left almost nothing to inspect, and the documentation had stopped matching the behavior.

There was no single incident, and they had been with Flatfile a long time. That is the shape most of these decisions take, and almost no vendor writes about it. Craig named three causes, none of them dramatic.

The platform was architected around different priorities. What a platform exposes reflects what its builders think you will need, and those assumptions had stopped matching. The parts Nisto needed visibility into were not the parts the platform exposed, and nobody had ever explained why.

There was not enough developer surface area to debug against. An import would break inside a layer Nisto did not control, and there was too little exposed to inspect. The next step after a failure was opening a ticket rather than reading a log, which put time to resolution on a schedule they did not set. The bigger the file the more that costs, because the failure modes that show up when handling large CSV files are exactly the ones you need to be able to see.

The documentation had gone out of date. When the docs and the behavior disagree, every debugging session starts by working out which of the two is lying, and that cost is paid on every incident rather than once. Stale docs were also the first visible signal that attention had moved.

His summary of the whole thing: it just wasn't fit for purpose.

"I didn't wake up one day and say Flatfile sucks. It's a marriage gone bad. All these things happen over time, and it's just one small thing after another after another."

Craig Schlegelmilch

What happened to Flatfile?

Flatfile has renamed itself Obvious. Its homepage, checked on 26 October 2026, describes "the AI agent that builds with you, not just for you" and talks about cleaning and restructuring spreadsheets, building dashboards from any data source, and turning data into slides. The embedded importer is not mentioned on that page. The Flatfile Portal pricing page is still live, headed "Flatfile is now Obvious," but tagged so search engines do not index it. Dromo's account of what happened to the Flatfile importer tracks the change in more detail.

Craig read the direction of travel from the outside, before any of it was announced.

"There's a reason why their docs aren't up to date. There's a reason why their architecture feels old and hasn't changed. It's because they're distracted. They're off doing something else."

Craig Schlegelmilch

The pricing overhang belonged to the same trajectory.

"We always knew that they were going to come back and ask for a completely different pricing model. They even told us that at one point. It was always this wasn't going to last forever. They just never said when."

Craig Schlegelmilch

A team can budget for expensive tools. It cannot budget for expensive at an unspecified date on unspecified terms.

What did they evaluate before choosing Dromo?

Nisto evaluated two vendors. An open source option did not survive the shortlist. OneSchema was ruled out on price: Craig called its floor "way too expensive," four figures a month minimum, and the usage based model he had looked at earlier had since been discontinued. Dromo won it.

Building it carried more weight than usual, because Craig had built a file importer at a previous company and it had worked. The pressure to revisit that is real and recurring, because a vendor invoice is a visible line item while the cost of maintaining your own importer is spread across people already on payroll, so the comparison tends to flatter the build. The full version of that calculation is in when to build versus buy a data importer.

"The smell test is no. I don't think it makes sense in the long run, simply because you will continue to capture edge cases that probably matter that we will never see."

Craig Schlegelmilch

A prototype takes days. Shaking it out takes months. And the volume of things Nisto has to maintain had started to be felt for the first time. The numbers behind that argument are set out in the true cost of building a CSV importer in house.

How long did the migration take?

Nisto reused much of its Flatfile codebase, which turned out to be generic enough to move.

"I just took everything we had with Flatfile, dropped it into all the events they told us to, and it just worked."

Nisto front end engineer, quoted by Craig Schlegelmilch

Craig's own verdict was measured rather than glowing, which makes it more useful: "it wasn't turnkey, but it was not hard." Nisto runs two schemas because they cut the count deliberately during the move, so that is a fact about Nisto rather than a limit in Dromo. They now run hundreds of imports a month.

Nisto is not the only team to move on that timescale. Waycool migrated from Flatfile to Dromo in under an hour, a different company with a different stack arriving at the same result.

What should you look for in a Flatfile replacement?

His reasons generalize into three questions worth asking every vendor on a shortlist.

Can you tell why it failed? Ask what you get to inspect when an import breaks, whether the documentation matches current behavior, and whether you can see what went in and what came out.

Is the scope right for your problem? Count what you would actually use. A platform built for collaborative, multi user work carries state, permissions, and concurrency whether or not you touch those features, and that surface area arrives on the day something breaks. Nisto's use case was narrow enough that two schemas cover every customer they have.

Can you predict the cost in two years? Ask whether the pricing model is published and whether it is stable. Dromo publishes its pricing for that reason, and a three way comparison of Dromo, Flatfile, and OneSchema sets the three side by side.

What Dromo commits to

Published pricing, no call required. The Professional plan is listed at $599 a month on the pricing page, with SOC 2 Type II certified and HIPAA compliant infrastructure included. You can model your own cost before you speak to anyone.

No repricing you did not see coming. Dromo is bootstrapped and profitable. There is no investor timeline forcing a pricing model change three years into your contract, which is exactly the overhang Nisto had been living with.

One product, and it is this one. Dromo builds an embedded data importer. There is no adjacent category it is drifting toward, and no reason for the documentation to fall behind the product.

A migration path built on purpose. Dromo's integration surface was designed so teams leaving Flatfile could carry existing logic across rather than rewrite it. That is why Nisto's engineer could drop their business logic into the equivalent events, and it is documented in Dromo's developer documentation.

What is different now?

Nisto can see inside the import, which is the one thing they could not do before.

The change Craig names first is visibility: Nisto can see what goes into the import and what comes out, which answers the original complaint directly. The narrower scope is the second, and he treats it as the feature rather than the compromise, because fewer abstractions means fewer that turn out to have been built for somebody else. The third is responsiveness, in that questions get answered and problems get solved, which was never the thing in dispute.

Nisto asked for one thing: post validation errors that come back attached to a specific row or cell the way pre validation errors already do. Dromo scoped an update to its hooks logic. That is the whole list. Hundreds of imports a month and one feature request is the outcome most teams are trying to buy.

Craig is careful not to oversell it. Nisto went live around March to April 2026, and he calls the relationship "still honeymoon."

"The platform we left with them did too much for the problems it was solving. Yours is simpler. It's tighter, but it does exactly what it says it does."

Craig Schlegelmilch

Should you move off Flatfile?

It depends on what you built, and the dividing line is clear: teams that never needed the collaborative multi user side move easily, and teams that did have more work to do.

The line runs through state, and it is the collaborative multi user workflow that Craig thought Flatfile was heading toward and Nisto never followed. If your importer takes a file, validates it, and hands the result to your backend, the work is remapping logic you already have onto a different set of events, which is what Nisto's engineer found. If several people edit the same import together and it has to remember where they left it, you are relying on behavior that has to be rebuilt rather than remapped.

For a longtime Flatfile user who never needed that side of it, the move is easy. Once things have to be stateful and multi user it gets more complicated, though not impossible. There is a step by step guide to migrating from Flatfile to Dromo, and a feature by feature comparison of Dromo and Flatfile sets out where the two products differ.

Frequently asked questions

Why are companies leaving Flatfile?

The most common reason is operability rather than price. Nisto's CTO said the deciding factor was losing the ability to tell why imports failed, which he traced to stale documentation, an architecture that had stopped changing, and too little developer surface area to debug against.

Is Flatfile shutting down?

No. The business continues to operate, under the name Obvious, with an AI agent as its lead product. That is a change of direction rather than a closure. Existing integrations did not stop working, which is part of why the shift went unremarked for so long.

What happened to Flatfile?

It changed its name and its lead product. The company now trades as Obvious, and its homepage describes an AI agent for cleaning spreadsheets, building dashboards, and producing slides; the embedded importer is no longer mentioned there. Customers tended to notice through the documentation and the architecture before any announcement.

What is the best Flatfile alternative in 2026?

There is no single answer, because it depends on volume, budget, and whether you need collaborative multi user editing. Ask three questions of any candidate: can you tell why an import failed, is the scope right for your problem, and can you predict the cost in two years. A wider survey of alternatives is the place to start.

How hard is it to migrate from Flatfile to Dromo?

It depends what you built. Nisto reused much of its Flatfile codebase, and its front end engineer described dropping the existing logic into the equivalent events. Their CTO called it "pretty painless" and said "it wasn't turnkey, but it was not hard." Collaborative, stateful workflows take longer.

Should I build my own CSV importer instead?

Nisto had built one before, successfully, and still decided against it. Their CTO's reasoning was that a prototype takes days but shaking it out takes months, and that a vendor with many customers keeps catching edge cases a single team would rarely encounter on its own traffic.

A wider survey of Flatfile alternatives and competitors covers the other vendors on a typical shortlist. Flatfile and Obvious references reflect what is published on their own sites, checked 26 October 2026.

The best measure of an import integration is how rarely anyone thinks about it.

"We don't really think about it anymore, which is good."

Craig Schlegelmilch, Chief Technology Officer, Nisto

That is the bar. The price is published, the sandbox is free, and nobody has to book a call to find out whether this works.