
Paragon
Six months of engineering work, our hardest project, done in 48 hours
6 months → 48 hrs
for a legacy migration attempted multiple times before
“I'm not exaggerating when I'm saying this changes everything for us.”
Ishmael CTO & Co-founder, Paragon
The challenge
The migration nobody had bandwidth for
Ishmael co-founded Paragon, an API integrations platform, with a co-founder who runs go-to-market. Before Paragon, the two of them ran a product studio together, building software for other companies. Paragon was the thing they built after they got tired of building other people's ideas.
Shipping anything at Paragon meant moving through a long chain before an engineer wrote a line of code. A stakeholder, whether sales, customer experience, or an internal team, flags a need. Research follows, figuring out the actual problem and what "done" looks like, usually through a lot of back-and-forth. Then a specification phase to nail down success criteria. Then engineering specs, which could take anywhere from a day to three or four weeks depending on the team. QA gets pulled in early to define test plans. Then development, then QA again, then feature flags and monitoring, then deploy. Then enablement sessions to walk stakeholders through the feature, then a marketing pass to announce it, all of it running underneath a constant stream of JIRA tickets, Slack updates, and check-ins. "So much more than the work itself," Ishmael said. "Probably a lot more than the work itself."
Scaling that process had only ever meant one thing: more engineers, more managers, more QA, coordinated across a globally distributed team spanning India, Brazil, Venezuela, and the US. "That's just really been my last four months," he said.
One project sat untouched inside that constraint for a long time: a legacy migration that other roadmap work depended on, but that the team kept deprioritizing because it was large enough to consume the bandwidth needed for everything else. Over 30,000 references to the system being migrated were scattered across the codebase, each one requiring real reasoning to untangle, not a mechanical find-and-replace. Ishmael called it "very, very, very scary."
The solution
The overnight migration
Ishmael's introduction to Obvious came secondhand and skeptical. His co-founder forwarded a Slack message: David, from Flatfile (now Obvious), was saying his engineers were shipping 2,500 pull requests a week, with ten engineers. Ishmael's reply: "2,500? How many engineers? ... 10. Get us connected." He got on a call with David still doubting the numbers, pushing on the mechanics: how do you move at that velocity without breaking things. The answers held up well enough that he booked a flight from Los Angeles to Obvious's Frontier cohort to see it for himself.
Before Autobuild touched any real work, it needed to understand Paragon's codebase: millions of lines, built up over years. It indexed the repo and produced a bibliography of it in about an hour. Ishmael has hired and managed engineers long enough to know what that comprehension normally costs. "It would take a very, very senior engineer not just months, probably like a year or two to understand all that context," he said. "And to get that level of fidelity in such a short time frame... that was a light bulb moment."
That was the opening he needed. At the cohort, he pointed Autobuild at the 30,000-reference migration and let it run overnight. The next morning: "It's been insane. We have essentially squeezed six months of work into 24 hours. And I have this thing running overnight. I think I'm going to wake up to essentially six to eight months of engineering work done autonomously overnight."
By the time the project reached a stopping point, it stood at 65 pull requests, still climbing. "I've been working on this thing," Ishmael said. "It's essentially six months of work, engineering work, our hardest project done in, like, 48 hours, by me, right? And I don't even touch the code base these days." His read on what changes goes past the code itself: if an agent can generate the spec, it can update a JIRA ticket, notify marketing, keep the loop moving. "If we solve the hard part," he said, "everything else is just administrative."
The result
What it means for Paragon
"The calculus of how I think about engineering and product is fundamentally different than it was three or four days ago," Ishmael said. Before the cohort, scaling Paragon's output meant scaling its headcount. After watching six months of work clear in two days, the constraint on what Paragon can build stopped being engineering capacity. What replaced it, in his words, is "how much money do I want to throw at it," because the work can be parallelized in a way hiring never scales fast enough to match.
He's planning to bring his engineering leads together in one room (his team is distributed across India, Brazil, Venezuela, and the US) to align on direction before running this at full velocity as a group. His estimate: "I think we can knock out six months of backlog in a week."
His one regret from the week is that more of Paragon's decision-makers weren't there to see it happen. "There'll always be hesitations until people see it for themselves."
"I think me flying here was the best decision I've made, potentially, probably this year. I don't think that's an extreme thing to say."

