Rescuing Orbi: How We Turned a 50-Second API Load Time into 200ms

We have been with Orbi from the very beginning. Our team at Yolk Studio built their brand from scratch, designed the MVP, and engineered the entire frontend of the application.

For the backend development, Orbi partnered with another large, highly established software agency. However, as we geared up for the beta launch and a major marketing push, a critical problem emerged from their side of the stack: the app was incredibly slow.

Some API requests were taking between 25 and 50 seconds to complete. If we launched marketing campaigns with those load times, the app would have been flooded with guaranteed one-star reviews. The entire project timeline suffered, and the beta launch was completely frozen.

To protect the product and save the launch, Yolk Studio stepped in and took over the backend codebase. It was a stark reminder of an industry reality we see often: paying for a massive agency name does not automatically guarantee quality engineering.

Here is how our team audited the inherited mess, found the needle in the haystack, and made a highly pragmatic engineering decision to save the launch.

The Investigation: Profiling the Bottleneck

When an API takes 50 seconds to respond, you don't guess—you measure. We immediately ran database, memory, and CPU profilers against the backend application.

The bottleneck quickly revealed itself. We detected ORM (Object-Relational Mapping) calls to the database that had unreasonably high allocation rates and massive execution times.

To isolate the issue, our engineers took the underlying SQL queries and executed them directly on the database. They ran perfectly fine, clocking in at around 150ms. The database engine wasn't the problem. The issue was how the application stack was talking to it.

After checking the related tables and column datatypes, we found a highly specific bug with the inherited stack: Entity Framework (EF) Core v6 paired with SQL Server. The previous agency had stored massive, unstructured JSON blobs inside NVARCHAR(MAX) columns. When EF Core v6 tried to retrieve these using asynchronous execution (.ToListAsync()), the performance completely tanked.

The Options: Textbook Purity vs. Business Reality

Because the problematic columns stored large, serialized JSON files, we mapped out three potential solutions to fix the architecture.

Option 1: Move the JSON to MongoDB The app was storing a lot of unstructured data across the entire data model. Moving to a NoSQL database like MongoDB is the textbook solution for handling unstructured JSON. However, the inherited architecture was so poor—lacking a proper repository layer and persisting requests directly from users—that implementing this stable solution would have taken an unreasonable amount of time, further delaying the launch.

Option 2: Change the Database Engine to PostgreSQL PostgreSQL has excellent native JSON support (jsonb), and the EF Core-PostgreSQL combination does not suffer from this specific performance bug. But completely swapping out the core database engine right before a launch is incredibly risky and requires deep investigation. We didn't have the luxury of time.

Option 3: The Pragmatic Fix (Disable Asynchronous Execution) The simplest, least glamorous solution was to stop using .ToListAsync() for these specific queries and just use synchronous .ToList() instead.

In textbook engineering, blocking threads is frowned upon. But at this phase, the app wasn't even in beta yet. As long as the server wasn't getting hit with 500 requests per second, the thread pool could easily handle a 100-300ms block.

We chose Option 3. It was the exact right move for the business.

The Outcome

By making a single, pragmatic code change, the results were instant. All API requests—even those pulling down massive 50MB responses—dropped to an average execution time of ~200ms. The CPU usage during these problematic requests became unnoticeable.

Orbi’s app was finally fast enough. The marketing freeze was lifted, and they successfully launched without the fear of performance-driven one-star reviews.

What We Learned

Taking over the Orbi backend reinforced three core principles we follow at Yolk Studio:

• Use the right tool for the job. Storing massive, unstructured JSON data in a relational SQL database is a recipe for disaster. At Yolk, we don't chase the hottest new frameworks, but we maintain deep expertise in a curated portfolio of tools so we know exactly when to deploy SQL versus NoSQL.

• Leverage the community. When you hit a bizarre framework bug, search the issue trackers. Smart people have likely already found the limits of your stack, and you can save days of debugging by reading the documentation.

• UX is the ultimate performance indicator. You can have the most elegant, asynchronous backend architecture in the world, but if the end user is staring at a loading spinner for 50 seconds, your app is failing.

If your digital product is crawling and you don't know why, your engineering team might be building for textbook purity rather than business reality.