DEV Community: qodors

AsNoTracking: The EF Core Setting Your Read Queries Are Missing

qodors — Fri, 10 Jul 2026 08:38:53 +0000

Most of the queries in a typical app are reads. You fetch data, show it, and never change it. EF Core doesn't know that. By default it assumes every entity you load might be modified and saved back, so it keeps track of all of them. That tracking has a cost, and on read-only queries you're paying it for nothing.

AsNoTracking() turns it off for a query. The data comes back the same, minus the bookkeeping.

What Tracking Actually Does
When EF Core runs a normal query, it doesn't just hand you objects. It takes a snapshot of every entity and holds a reference to it in the change tracker. That's how SaveChanges() knows what changed — it compares the current state of each tracked entity against the snapshot it took when the entity was loaded.

That's what you want when you're updating. When you load a customer, change their email, and call SaveChanges(), the tracker is what figures out that one field changed and writes the UPDATE.

When you're loading a list of orders to render on a page, none of it matters. You're not saving anything, but EF Core still builds the snapshots and holds the references anyway, doing comparison work it will never use.

Where the Cost Shows Up

var orders = await _db.Orders
     .Where(o => o.CreatedAt > lastWeek)
     .ToListAsync();

This tracks every order it returns. Ten rows, fine. A few thousand rows on a reporting screen, and the tracking overhead becomes real — extra memory for the snapshots, extra CPU building them, and a change tracker now holding references to thousands of entities it'll never save.

Add AsNoTracking() and that goes away:

var orders = await _db.Orders
     .AsNoTracking()
     .Where(o => o.CreatedAt > lastWeek)
     .ToListAsync();

Same SQL. Same data back. EF Core skips the snapshot and doesn't retain the entities. On large read queries the difference in memory and time is measurable, and it costs you one method call.

The Bug That Tracking Hides
There's a second reason this matters, and it's not about performance.

Because the change tracker holds references to everything it loads, it also returns the same instance if you query the same row twice in one context. Sometimes that's convenient. Sometimes it hides a problem — you edit a tracked entity somewhere, and a completely separate read query later hands back your modified version instead of what's actually in the database, because the tracker gave you the cached instance.

With AsNoTracking(), every query goes to the database and gives you a fresh object. For read paths, that's usually what you actually want.

When You Should Not Use It
AsNoTracking() is for reads. The moment you plan to change an entity and save it, you need tracking on, because that's the mechanism that detects the change.

var customer = await _db.Customers
     .FirstAsync(c => c.Id == id);
customer.Email = newEmail;
await _db.SaveChanges();   // works because customer is tracked

Put AsNoTracking() on that query and SaveChanges() does nothing — EF Core isn't tracking the entity, so it has no idea anything changed. No error, no update, the email silently stays the same. The code looks correct, which is what makes it hard to find.

So the line is simple: reading and displaying, use AsNoTracking(). Loading something to modify and save, don't.

Doing It Everywhere Without Repeating Yourself
If most of your app is reads, adding AsNoTracking() to every query gets tedious and easy to forget. You can flip the default for a whole context:

optionsBuilder.UseSqlServer(connectionString)
     .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking);

Now queries are no-tracking by default, and you opt back in on the queries that actually write, using .AsTracking(). For a read-heavy app this is often the better default — you stop paying for tracking everywhere and only turn it on where you need it.

Just make sure the team knows the default changed. Someone who assumes tracking is on will write the update code above and watch SaveChanges() quietly do nothing.

Our Take
At Qodors, when we profile a read-heavy .NET app that's using more memory than it should, tracking is a regular offender. It rarely shows up as a crash or an obvious error. It shows up as a service that holds more memory than the data justifies, or a request that's slower than the size of its result set explains.

It connects to something we've written about before — a query returning far more rows than it should because of the wrong IQueryable/IEnumerable return type. Fix that so you're loading the right rows, then add AsNoTracking() so you're not paying to track the read-only ones. The two together cover a large share of the EF Core performance problems we see.

It's default behavior that happens to be correct for writes and wasteful for reads, running in an app that mostly reads.

Quick Checklist
Add AsNoTracking() to queries that only read and display data
Leave tracking on for any query where you'll modify the entity and call SaveChanges()
For read-heavy apps, consider QueryTrackingBehavior.NoTracking as the context default and opt back in with .AsTracking()
If SaveChanges() silently does nothing, check whether the entity was loaded with AsNoTracking()
Watch for stale data from the change tracker returning a cached instance on read paths
Pair it with correct IQueryable return types so you're tracking fewer, and the right, rows

Tracking is on by default because EF Core can't tell a read from a write. On the queries where you're only reading, tell it. That's the whole optimization.

DotNet #CSharp #EFCore #EntityFramework #Performance #BackendDevelopment #SoftwareEngineering #DotNetCore #SQL #QodorsEdge

Written by the team at Qodors — we profile and fix slow, memory-hungry .NET apps. → www.qodors.com

IQueryable vs IEnumerable: The Mistake That Loads Your Whole Table

qodors — Thu, 09 Jul 2026 10:40:48 +0000

You wrote a clean LINQ query. It filters down to ten rows. It runs fine in dev, and then in production it's slow and your database CPU is higher than it should be for such a small result.
The query looks right. The problem is where the filtering happens. With IEnumerable, the filter runs in your app after the whole table is already loaded from the database. With IQueryable, the filter becomes part of the SQL and runs in the database. Same LINQ, completely different amount of data moving across the wire.
Get this wrong on a large table and you're pulling every row into memory to throw almost all of them away.

The Two Interfaces
Both let you write .Where(), .Select(), .OrderBy(). That's why they get mixed up. The difference is when and where the query executes.
IEnumerable works on objects already in memory. When you call .Where() on it, the filtering happens in your application, in C#, row by row. If the data came from a database, it's already been loaded in full before your filter ever runs.
IQueryable builds an expression tree instead of running anything immediately. EF Core takes that tree and translates it into SQL. Your .Where() becomes a SQL WHERE clause, and the database does the filtering before it sends anything back.
Same method names. One filters in the database, the other filters in your app after the table is already loaded.

Where It Goes Wrong
Here's the line that causes it:

public IEnumerable<Order> GetOrders()
{
    return _db.Orders;   // returns IEnumerable
}

The method returns IEnumerable. The moment you expose it as IEnumerable, any .Where() a caller adds runs in memory, not in SQL:

`var recent = GetOrders().Where(o => o.CreatedAt > lastWeek);`

That .Where() looks like it filters in the database. It doesn't. GetOrders() already returned an IEnumerable, so EF Core loads the entire Orders table into memory, and then C# filters it down to last week's rows. On a table with a few hundred rows you'd never notice. On a table with two million, it's a disaster.
Now the version that does what you expect:

public IQueryable<Order> GetOrders()
{
    return _db.Orders;   // returns IQueryable
}

var recent = GetOrders().Where(o => o.CreatedAt > lastWeek).ToList();

Because GetOrders() returns IQueryable, the .Where() gets folded into the query, and EF Core generates SQL like this:

SELECT [o].[Id], [o].[CustomerId], [o].[CreatedAt], [o].[Total]
FROM [Orders] AS [o]
WHERE [o].[CreatedAt] > @lastWeek

The database filters first and sends back only the rows you asked for. Same calling code. One returns two million rows over the wire, the other returns a handful.

The Trap Is the Return Type
The mistake almost always hides in a method signature. Someone writes a repository or service method that returns IEnumerable because it feels safer or more general. Every caller that adds a filter after that point is filtering in memory, and nobody notices until the table grows.
AsEnumerable() and ToList() do the same thing on purpose. The moment you call either, everything after it runs in memory:

var recent = _db.Orders
.ToList()                              // whole table loaded here
    .Where(o => o.CreatedAt > lastWeek);   // filters in memory

Move the .Where() before the .ToList() and it runs in SQL. The order matters, and it's easy to get backwards.

When You Actually Want IEnumerable
This isn't "always use IQueryable." Once the data is in memory, IEnumerable is the right type, and forcing IQueryable where it doesn't belong just adds confusion.
If you've already loaded a list and you're filtering it in code, that's IEnumerable and that's correct. If you're working with an in-memory collection that never touched a database, there's no SQL to translate to, so IQueryable buys you nothing. And there are queries EF Core can't translate to SQL — certain method calls or custom C# logic — where you have to pull the data into memory first and finish the work there. That's a real case, just do it deliberately, not by accident through a return type.
The point isn't to fear IEnumerable. It's to know which one you're holding and where the filtering will run.

Our Take
At Qodors, when a .NET app has queries that are slow out of proportion to the data they return, this is one of the first things we look at. The query reads fine. The LINQ is correct. The problem is a method three layers down that returns IEnumerable, quietly loading a whole table so the app can filter it in memory.
It hides well because it doesn't fail. Small tables in development behave normally, tests pass, and it only turns into a problem when real data volume shows up. By then it looks like a database performance issue, and people go tuning indexes when the fix is a return type change from IEnumerable to IQueryable.
Check what your repository and service methods return. If they hand back IEnumerable from an EF Core query, your filtering probably isn't happening where you think it is.
Quick Checklist
Return IQueryable from repository/service methods that wrap EF Core queries, so callers filter in SQL
Watch every ToList() and AsEnumerable() — everything after it runs in memory
Keep .Where() and .Select() before you materialize with ToList()
Use IEnumerable for data that's already in memory — that's what it's for
If a query genuinely can't translate to SQL, pull it into memory on purpose, not by accident
When a query is slow for the rows it returns, check the return types up the call chain
IQueryable and IEnumerable share the same LINQ methods, which is exactly why the bug is easy to write and hard to spot. One filters in the database. The other loads the table first and filters in your app.
Know which one your method returns. That one decision is the difference between a query that touches ten rows and one that drags two million across the wire.

DotNet #CSharp #EFCore #LINQ #EntityFramework #BackendDevelopment #SoftwareEngineering #DotNetCore #Performance #QodorsEdge

Written by the team at Qodors — we fix .NET apps with queries slower than they should be. → www.qodors.com

Dependency Injection in .NET Is Easy to Get Wrong

qodors — Wed, 01 Jul 2026 09:53:11 +0000

Almost every weird intermittent bug I've dealt with in a .NET app traced back to one place: a service registered with the wrong lifetime in Program.cs. Not the logic inside the service. The single line that said how long it should live.

DI itself is built into .NET and easy to start with. You register your services, ask for them in a constructor, and the framework hands them over. The part that trips people up isn't wiring it together. It's the lifetimes.

Get a lifetime wrong and the app still starts, requests still succeed, and everything looks healthy. The damage shows up later as stale data, or state bleeding between users, or memory that climbs and never drops back down.

The Three Lifetimes

There are three, and the whole thing hinges on understanding them.

*Transient *— you get a new instance every time you ask for one. Two things in the same request that both need it get two separate copies.

*Scoped *— you get one instance per request. Everything in a single HTTP request shares the same instance, and the next request gets a fresh one.

*Singleton *— you get one instance for the entire lifetime of the app. Every request, every user, shares the exact same object.

builder.Services.AddTransient<IEmailSender, EmailSender>();
builder.Services.AddScoped<IOrderService, OrderService>();
builder.Services.AddSingleton<ICacheProvider, CacheProvider>();

That's the whole API. Three methods. Picking the wrong one of the three is where most of the trouble comes from.
The Captive Dependency

This is the one that gets almost everybody at some point.

You have a singleton. Inside it, you inject something scoped. It compiles, it runs, and it looks fine. But you've just trapped a scoped service inside a singleton.

The singleton is created once and lives forever. The scoped service it grabbed gets held onto for that whole time, instead of being created fresh per request like it's supposed to. So now a service that was meant to live for one request is stuck living for the entire app.

public class CacheProvider : ICacheProvider   // registered as Singleton
{
    private readonly AppDbContext _db;         // this is Scoped

    public CacheProvider(AppDbContext db)      // now the DbContext is captive
    {
        _db = db;
    }
}

DbContext is the classic victim. It's registered scoped for a reason. It's not built to be shared across requests, it tracks changes and holds a connection, and when you trap it inside a singleton you get stale data, threading errors, and connection problems that are miserable to track down.

The rule that keeps you safe: a service can only depend on things that live as long as it does, or longer. A singleton can depend on a singleton. A scoped service can depend on scoped or singleton. But a singleton depending on scoped is the trap.

The good news is that .NET can catch this for you. There's a scope validation check that throws at startup when a singleton depends on something scoped, and it's on by default in the Development environment. Don't turn it off. If it throws, it's telling you about a real bug before it reaches production.
Singletons Holding State

The other common mistake is making something a singleton without thinking about what it holds.

A singleton is shared across every request at the same time. If it has mutable state — a field it writes to, a dictionary it updates, a list it appends to — then multiple requests are hitting that state at once, on different threads. That's a race condition, and it shows up as data from one user leaking into another user's request, or numbers that don't add up.

If a service is a singleton, either it holds no state, or the state it holds is safe for many threads to touch at once. A stateless helper is fine as a singleton. A cache built on a thread-safe collection is fine. A service that quietly keeps per-user data in a plain field is not.
So Which One Do You Pick

For most things, the answer is scoped, and that's also the default for a reason.

Scoped fits how web requests work. One instance per request, fresh state each time, cleaned up when the request ends. Your services that touch the database, handle business logic, or deal with the current user should almost always be scoped.

Use transient for small, cheap, stateless things where a new instance every time costs nothing. Use singleton for things that are genuinely shared and either hold no state or are built to be thread-safe — configuration, a connection factory, an in-memory cache.

When you're not sure, scoped is the safe default. Reaching for singleton to "save memory" is where people get into trouble, and the memory you save is almost never worth the bugs you buy.
Our Take

At Qodors, when we're brought into a .NET app with weird intermittent bugs — stale data, state bleeding between users, memory that only grows — DI lifetimes are near the top of the list we check. It's rarely the code inside the service that's broken. It's how the service was registered.

What makes it hard is that the wrong lifetime doesn't fail loudly. The app starts, requests succeed, everything looks healthy. The problem only surfaces under real concurrent traffic, and by then it looks like a dozen unrelated bugs instead of one registration mistake.

Turn on scope validation, default to scoped, and think for a second before you make anything a singleton. Most DI problems never happen if you do those three things.
Quick Checklist

Default to scoped unless you have a clear reason not to
Never inject a scoped service into a singleton (the captive dependency)
A service can only depend on things that live as long as it does, or longer
Keep scope validation on in Development — don't silence it
Singletons must be stateless or genuinely thread-safe
DbContext stays scoped — don't trap it in a singleton

The wrong lifetime is a one-line mistake that hides for weeks. It doesn't break the build and it doesn't throw in testing. It waits for real traffic, then hands you a pile of bugs that look unrelated until you trace them back to a single registration.

Default to scoped, keep scope validation on, and be deliberate about singletons.

DotNet #CSharp #DependencyInjection #AspNetCore #BackendDevelopment #SoftwareEngineering #DotNetCore #StartupCTO #QodorsEdge

Written by the team at Qodors — we fix .NET apps with weird intermittent bugs. → www.qodors.com

Stop Using .Result and .Wait() in Your .NET Code

qodors — Wed, 24 Jun 2026 12:00:41 +0000

Your app works fine in testing. You deploy it, a few users come on, and then it just... hangs. No error, no crash. The request sits there until it times out.

You check the logs. Nothing useful. You restart the app and it's fine again for a while, then it locks up again under load.

If you've got .Result or .Wait() anywhere in your code, that's very likely your problem. They look harmless. They're not.
What These Actually Do

.Result and .Wait() take an async method and force it to run synchronously. You've got a Task and you want the value now, without making your method async, so you write:

var data = GetDataAsync().Result;

It compiles. It works on your machine. It looks like a quick way to avoid turning half your code async.

What it actually does is block the current thread and tell it to sit and wait until the async operation finishes. And in certain setups, that wait never ends.
The Deadlock

Here's how it locks up.

In older ASP.NET (and some desktop apps), there's a synchronization context that controls which thread continues after an await. When the async work finishes, it tries to come back to the original thread to continue.

But that original thread is the one you blocked with .Result. It's sitting there waiting for the async work to complete. The async work is waiting for that thread to be free so it can finish. Neither one gives way.

The request hangs. No exception, no log line, nothing. Just a thread stuck forever, and eventually a timeout. Do this enough times under load and you run out of threads, and the whole app stops responding.

The worst part is it often doesn't show up in testing. One request at a time on your machine works fine. It's only under real traffic, with the thread pool under pressure, that it falls apart. So it passes your tests and breaks in production.
The Fix Is Boring

Don't block. Go async the whole way.

var data = await GetDataAsync();

That's it. Make your method async, return a Task, and await the call instead of reaching for .Result.

The rule people say for this is "async all the way." If a method calls something async, it should be async too, and so should the method that calls it, up the chain. Once one part of your code is async, that tends to spread upward, and that's fine. That's how it's supposed to work.

public async Task<Customer> GetCustomerAsync(int id)
{
    var customer = await _repository.GetByIdAsync(id);
    return customer;
}

No blocking, no deadlock, and the thread is free to handle other requests while it waits.
"But I Can't Make This Method Async"

This is the usual reason people reach for .Result. A constructor can't be async. A property getter can't be async. Some old interface you have to implement isn't async.

Most of the time the real fix is to move the async work somewhere it belongs. Don't do database calls in a constructor. Don't run async work inside a property. If you've got async work stuck inside something that can't be async, that's usually a sign the work is in the wrong place, not a sign you need to block.

There are a few genuine exceptions. The Main method in older console apps sometimes had to block (modern .NET lets Main be async, so this is mostly gone). And there are rare spots in framework-level code where you're truly stuck. But those are rare. If you're reaching for .Result in your normal request-handling code, it's almost never one of those cases.
A Note on ConfigureAwait

You'll see advice to use ConfigureAwait(false) to avoid the deadlock:

var data = await GetDataAsync().ConfigureAwait(false);

This tells the await it doesn't need to come back to the original thread, which sidesteps the deadlock. It's worth using in library code. But treat it as a safety net, not a fix. The actual fix is to not block in the first place. If your code is properly async all the way through, you don't have the deadlock to work around.
Our Take

At Qodors, when a .NET app hangs under load with no error in the logs, .Result and .Wait() are one of the first things we grep for. It's a common one, and it's nasty precisely because it hides during testing and only shows up when real users arrive.

The fix is rarely complicated. It's usually just making a chain of methods async that should have been async from the start. It feels like more work than slapping .Result on the end of a call, and that's exactly why people skip it. Then they spend a week chasing a production hang that a single await would have prevented.

Async all the way isn't a style preference. It's how the thing is meant to be used.
Quick Checklist

Search your codebase for .Result and .Wait() — find every one
Anywhere in request-handling code, replace blocking with await
Make the calling methods async Task up the chain
If async work is stuck in a constructor or property, move it out
Use ConfigureAwait(false) in library code as a safety net, not a substitute for going async

.Result and .Wait() are quick to type and they'll pass your tests. Then they hang in production with no error to point you at the cause.

Go async properly and the problem never shows up. That's the whole trade.

DotNet #CSharp #AsyncAwait #AspNetCore #BackendDevelopment #SoftwareEngineering #Performance #DotNetCore #StartupCTO #QodorsEdge

Written by the team at Qodors — we fix .NET apps that hang under load. → www.qodors.com

Entity Framework Is Slow. It's Not EF's Fault.

qodors — Sat, 20 Jun 2026 12:00:56 +0000

Your API was quick in development. Then traffic picks up and a few endpoints start taking three seconds to respond.

You open the code, see Entity Framework everywhere, and figure that's the culprit. Time to rip it out and write proper SQL.

Don't. Before you throw away the thing saving you thousands of lines of code, look at what it's actually doing. Most of the time EF isn't slow. It's doing exactly what your code asked, and your code asked for something expensive.
EF Does What You Tell It

Entity Framework writes SQL for you. That's the point, and it's useful. The downside is that one clean-looking line of C# can turn into a query that hammers your database, and nothing in the code tells you that's happening.

The SQL is hidden, so the cost is hidden too. That's usually where things go wrong.

Below are the four things that actually slow EF down. None of them are EF being slow.
1. The N+1 Problem

This is the big one. Almost every slow EF app has it somewhere.

You load a list of orders, loop through them, and read order.Customer for each one:

var orders = context.Orders.ToList();
foreach (var order in orders)
{
    Console.WriteLine(order.Customer.Name);
}

EF didn't load the customers when it loaded the orders. So the first line runs one query, and then every time you touch order.Customer it goes back to the database for that one customer. A hundred orders, a hundred and one queries.

Tell EF to load the customers with the orders and the problem goes away:

var orders = context.Orders
    .Include(o => o.Customer)
    .ToList();

Same data on screen, one query instead of a hundred and one.
2. Loading Whole Entities for Two Fields

Say you need a list of customer names and emails for a page. The easy version:

var customers = context.Customers.ToList();

EF pulls every column of every customer and builds a full object for each. Addresses, notes, timestamps, everything. You needed a name and an email.

Project down to what you'll actually use:

var customers = context.Customers
    .Select(c => new { c.Name, c.Email })
    .ToList();

Now it's two columns. Less data read, less memory spent building objects you were never going to look at.

3. Tracking You Don't Need

EF tracks every entity it loads so it can figure out what changed when you call SaveChanges. That's needed when you're updating something. It's pure overhead when you're just reading data to show it on a screen and you'll never touch it again.

For read-only queries, switch tracking off:


var products = context.Products
    .AsNoTracking()
    .ToList();

On a large result set this matters, because EF stops building and holding all the change-tracking state it was never going to use.

Filtering in C# Instead of the Database

This one is easy to miss and it hurts badly:


var activeUsers = context.Users
    .ToList()
    .Where(u => u.IsActive);

The ToList() runs first. That pulls every user into memory, and only then does the Where filter them in C#. Two million users, fifty active, and you've loaded all two million to keep fifty.

Move the filter ahead of ToList() so it ends up in the SQL:

var activeUsers = context.Users
    .Where(u => u.IsActive)
    .ToList();

Now the database filters and hands you fifty rows. Same two lines, swapped order, completely different behaviour under load.
See What EF Is Doing

You don't have to guess about any of this. EF can log the SQL it generates. Turn it on in your DbContext setup:

optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information);

Run the app, hit the slow endpoint, read the output. The same SELECT firing over and over in a loop is your N+1. A query dragging out thirty columns when you needed two is your projection problem. It's all there.

Most teams never look. They treat EF as a black box and blame it when things get slow. It isn't a black box. The SQL is sitting in the logs the whole time.
When Raw SQL Is Actually Worth It

EF isn't always the right call. A heavy reporting query with several joins, grouping and aggregation can genuinely be faster and clearer as hand-written SQL or a stored procedure. Use raw SQL there. EF doesn't have to handle everything.

But that's a small part of a normal app. The everyday reads and writes that make up most of your code are fine in EF once you've stopped tripping over the four things above. Rewriting your whole data layer because a handful of queries are slow is a huge amount of work to fix something that usually lives in four or five places.

Find the slow queries first. Then decide.
Our Take

At Qodors, when a client says EF is slow and wants it gone, the first thing we ask for is the generated SQL. Nobody writes raw SQL until we've seen that.

It's almost always the same short list. An N+1 that needs an Include. A query loading full entities where a projection would do. Read-only queries that should be AsNoTracking. A filter sitting on the wrong side of a ToList(). Fixing those is usually a day of work, and it gets you most of the speed people were hoping a full rewrite would buy.

EF is a tool. Hand it careless code and it produces expensive queries. That's worth understanding before you decide the framework is the problem.
Before You Rip Out EF

Turn on SQL logging and read what EF actually generates
Look for the same query firing in a loop, then fix it with Include
Check whether you're loading full entities where a Select would do
Make sure read-only queries use AsNoTracking
Check for any .Where sitting after a .ToList() instead of before it

EF will happily generate bad SQL if your code asks for it. The fix is almost never ripping it out. Read the queries first. Most teams find the framework was never the problem.

DotNet #EntityFramework #CSharp #EFCore #AspNetCore #BackendDevelopment #SoftwareEngineering #Performance #StartupCTO #QodorsEdge

Written by the team at Qodors — we make slow .NET systems fast without rewrites. → www.qodors.com

Technical Debt: The Bill Always Comes Due

qodors — Wed, 17 Jun 2026 11:28:40 +0000

You needed to ship fast. So you took shortcuts.

You hardcoded a few values. Skipped some tests. Copy-pasted a function instead of cleaning it up. Dropped a // TODO: fix this later and kept moving.

And it worked. You shipped, the feature went live, the deadline got hit.

That was six months ago. These days every new feature takes longer than it should. You change something small and something unrelated breaks. A new developer joined last month and still can't work in half the codebase because nobody can really explain how it fits together. The shortcuts you took back then are the reason.
What Technical Debt Actually Is

Technical debt is the cost you pay later for moving fast now.

It isn't automatically bad. Sometimes a shortcut is the right call. A startup that ships a slightly messy product and survives beats a perfect one that ships late and runs out of runway. Nobody should feel guilty about that trade.

The trouble starts when you take on debt without realizing it, and then never go back to deal with it.

Some debt you choose. You knew the clean way to do it, you had a deadline, and you picked the fast way on purpose. That's fine, assuming you actually circle back.

The other kind nobody chooses. The code just drifts. Patterns get copied without thought, old decisions stop making sense, and no one updates them. This is the kind that does the real damage, because there's no decision anywhere and nobody's keeping track of it. It just accumulates while you're busy with other things.
How You Know It's Piling Up

You can usually feel it before you can measure it:

A small change takes far longer than it should
Fixing one thing breaks two others
People are nervous about touching certain files
New hires take weeks to get productive
"Don't touch that, it works and nobody knows why"
More of your time goes to maintenance than to building anything new

A team that gets slower every month instead of faster usually isn't a team problem. It's the codebase quietly fighting back.
Why It Gets Expensive

Debt is cheap at the start, which is exactly what makes it dangerous.

One messy function is nothing. You work around it. But messy code tends to breed more of it, because the next person copies whatever's already there. One shortcut turns into ten, and ten turns into a system nobody fully understands anymore.

Then it starts costing you in ways you can actually measure. Features that used to take two days take a week, because the code fights you the whole way through. Bugs go up, since touching one thing breaks another, and you burn time fixing regressions instead of building. Good engineers get tired of it and leave, because nobody wants to spend their days wrestling a codebase nobody maintains. And when a competitor ships something in a week, you need a month, because your foundation can't carry the weight.

That's the part that stings. The mess you accepted to move fast eventually becomes the thing stopping you from moving fast.
How to Actually Deal With It

You don't fix this by halting everything for a big rewrite. That almost never works, and it's a separate conversation. You handle it gradually.

Make it visible. You can't manage what nobody can see. When someone takes a shortcut, write it down somewhere — a ticket, a list, a doc, whatever your team will actually look at. The most dangerous debt is the kind nobody is tracking.

Pay a little, regularly. Don't wait for the cleanup sprint that never gets scheduled. Carve out a slice of every cycle, somewhere around 15 to 20 percent, for chipping away at it. Small steady effort gets further than one heroic fix that keeps getting pushed.

Clean what you're already in. When you're working in a messy file anyway, tidy it up a little before you leave. Not a rewrite, just a bit better than you found it. Over time the areas you touch most often quietly get cleaner.

Take on new debt deliberately. Some shortcuts are worth it. Just make it a real decision instead of an accident. "We're cutting this corner to hit the launch and fixing it in Q2" is a plan. Messy code with no plan behind it is just a problem waiting to grow.
Our Take

At Qodors, we don't tell clients to avoid technical debt. That advice isn't realistic and it isn't even good. Speed matters, especially early on.

What we tell them is to know what they're taking on and deal with it before it starts dictating the roadmap. The teams that are still shipping fast in year three aren't the ones who wrote perfect code from day one. They're the ones who didn't let the shortcuts quietly stack up into a wall.

Handled deliberately, debt is just part of building software. Ignored, it sets the pace for everything you do next.
Questions Worth Asking Your Team

Do you actually know where your biggest debt is, or is it just "everywhere"?
Are you paying any of it down regularly, or only when something breaks?
Has the team been getting slower month over month? Do you know why?
When someone takes a shortcut, does it get written down anywhere?
Is there a file everyone avoids? That's probably your most expensive debt.

Borrowing speed is fine. Most teams should.

Just don't forget you borrowed it, because the longer that sits, the more it ends up costing you.

TechnicalDebt #SoftwareEngineering #EngineeringManagement #StartupCTO #TechLeadership #CodeQuality #SoftwareDevelopment #EngineeringCulture #QodorsEdge

Written by the team at Qodors — we help startups keep their codebase fast as they grow. → www.qodors.com

Your Database Is Fast. Your Queries Are Slow.

qodors — Wed, 10 Jun 2026 12:34:33 +0000

Your app was fast when you launched. A few months later, it's slow.

So you upgrade the database. More CPU, more RAM, a bigger plan. It gets better for a week, then it's slow again.

Most teams upgrade a second time here. Don't.

The database is probably fine. Postgres can handle millions of rows without a problem. The issue is how your app asks for the data.
The Real Problems

When an app gets slow, people blame the server. Usually it's one of these four things. None of them get fixed by a bigger server.

1. Missing Indexes

This is the most common one.

Run WHERE email = 'user@example.com' on a table with no index, and Postgres has to check every row to find the match. With 500 rows, you won't notice. With 5 million, you wait.

An index is like the index in a book. Instead of reading every page, you go straight to the right one.

sql

CREATE INDEX idx_users_email ON users(email);

That one line can take a query from 4 seconds to a few milliseconds. No new server needed.

Don't add an index to every column though. Each one slows down writes a little and uses storage. Add them to the columns you search, join, and sort on.

2. The N+1 Query Problem

This one hides inside your ORM.

You load 100 posts. Then your code reads post.author for each one. That's 1 query for the posts and 100 more for the authors. 101 queries to load one page. And your code looks normal.

1 query: SELECT * FROM posts LIMIT 100 100 queries: SELECT * FROM users WHERE id = ? (one per post)

The fix is to load the authors all at once:

SELECT * FROM posts LIMIT 100
SELECT * FROM users WHERE id IN (1,2,3,...)

Two queries instead of 101. Your ORM can do this. It's usually called eager loading. You just have to remember to use it.

3. SELECT * Everywhere

You need a name and an email. You write SELECT * because it's quick. Now you're pulling all 30 columns, including a big JSON field and a base64 image you don't need.

You're sending megabytes to use two fields.

sql

SELECT id, name, email FROM users WHERE id = 42

Ask for what you need. It reads less from disk, sends less over the network, uses less memory.

4. No Pagination

SELECT * FROM orders is fine with 50 rows on your laptop.

In production with 2 million orders, it tries to load all of them at once. The query times out or the server runs out of memory. Nobody needs 2 million rows on one screen.

sql

SELECT * FROM orders ORDER BY created_at DESC LIMIT 20 OFFSET 0

Show 20. Let them load the next 20.
Don't Guess. Use EXPLAIN.

You don't have to guess which query is slow. Postgres tells you.

sql

EXPLAIN ANALYZE SELECT * FROM users WHERE email = 'user@example.com';

Look at one thing:

Seq Scan — Postgres is reading the whole table. On a big table, that's your problem.
Index Scan — Postgres is using an index. Good.

See a Seq Scan on a big table in a slow query? Add an index. You found it.
Why a Bigger Server Doesn't Help

A bigger server makes a slow query a little less slow. It doesn't fix it.

A missing index means scanning millions of rows. A faster CPU scans those rows a bit faster, but it still scans all of them. You pay more to do the same wasted work. The N+1 page that runs 101 queries still runs 101 queries on a bigger box. More RAM doesn't make your code ask for data better.

A bigger server buys you time. Sometimes that's worth it before a launch. But it's a patch, and it's expensive. You still have to fix the query later.
Our Take

At Qodors, when a client says their database is slow, the server size is the last thing we check, not the first.

Almost every time, the fix is in the queries:

Indexes on the columns that get used
Fixing N+1 with eager loading
Selecting only the columns you need
Paginating anything that can grow
Reading EXPLAIN ANALYZE instead of guessing

None of this costs money. It costs some time. And it usually beats doubling your server.

Your database can handle far more than you're giving it. The real question is whether your queries are getting in the way.
Before You Upgrade

Check these first:

Are your common queries indexed? Run EXPLAIN and look for Seq Scan on big tables.
How many queries does one page run? Count them. The number is often higher than you think.
Are you pulling 30 columns to use 2?
Is anything unpaginated that could grow large?
Have you profiled it, or are you about to buy RAM on a guess?

A bigger server hides the problem.

Fixing the queries removes it.

Start with the queries. Most teams find they had enough database the whole time.

Database #PostgreSQL #SQL #PerformanceOptimization #BackendDevelopment #SoftwareEngineering #StartupCTO #TechLeadership #QodorsEdge

Written by the team at Qodors — we make slow systems fast without throwing money at hardware. → www.qodors.com

Your Microservices Aren't Microservices

qodors — Fri, 05 Jun 2026 09:40:35 +0000

You split your monolith into 12 services. You're doing microservices now.

Except every service calls every other service. Deploy one, you have to deploy all of them. One goes down, the whole system goes down.

You didn't build microservices. You built a distributed monolith.

You took a system that ran in one place and scattered it across the network — keeping all the tight coupling, but adding latency, failure points, and DevOps pain on top.

This is the worst of both worlds. And most teams don't realize they're in it until production is on fire.
How You Got Here

It usually starts with good intentions.

The monolith felt slow and scary. Microservices were the answer everyone preached. So you started splitting.

But you split by technical layers, not by business domains. You created a "database service," an "auth service," a "notification service" — and they all depend on each other to do anything useful.

Now placing an order touches eight services in a single request. Each call adds network latency. Each service is a new place to fail.

You didn't decouple anything. You just added network calls between functions that used to be a simple method call.
The Signs You Have a Distributed Monolith

Be honest. How many of these are true?

You can't deploy one service without deploying others
One service going down takes the whole system with it
A single user action triggers a chain of 5+ service calls
Services share the same database
You need all services running locally just to test one feature
Changing one service's API breaks three others

If you nodded at three or more, you don't have microservices. You have a monolith with extra network latency and a much harder deployment story.
Why This Is Worse Than a Monolith

A regular monolith has one real advantage: simplicity.

One deploy. One process. Function calls are instant. Debugging is straightforward. Transactions are easy.

A distributed monolith throws all of that away and gives you nothing in return:

**Network latency **on every internal call
**Partial failures **— service A succeeds, service B fails, now your data is inconsistent
**Distributed debugging **— tracing a bug across 8 services and 4 logs
**Deployment coordination **— you can't ship one thing without shipping everything
**Operational overhead **— monitoring, scaling, and securing 12 services instead of 1

You took on all the complexity of distributed systems and kept all the coupling of a monolith.
What Real Microservices Look Like

True microservices are independent. That's the entire point.

1. Split by Business Domain, Not Technical Layer

Don't build a "database service." Build an "Orders service" that owns everything about orders — its logic, its data, its rules.

Each service is a complete vertical slice of business capability. It can do its job without constantly asking others for help.

2. Each Service Owns Its Data

No shared databases. The Orders service has its own database. The Inventory service has its own. They never reach into each other's tables.

If Orders needs inventory data, it asks through an API or an event — it doesn't query Inventory's database directly.

3. Services Communicate Loosely

Where possible, use asynchronous events instead of synchronous calls.

When an order is placed, the Orders service emits an OrderPlaced event. Inventory and Notifications react to it on their own. Orders doesn't wait. Orders doesn't even know who's listening.

If Notifications is down, orders still go through. That's independence.

4. Independent Deployment

You should be able to deploy the Orders service at 2 PM on a Tuesday without touching anything else. No coordination. No "deploy everything together" ritual.

If you can't, your services are still coupled.
The Honest Truth About Microservices

Most startups don't need microservices at all.

A well-structured monolith — clean modules, clear boundaries, one database — will take you further than you think. Often all the way to serious scale.

Microservices solve organizational problems more than technical ones. They let large teams work independently on separate parts of a system. If you have 8 engineers, you probably don't have that problem yet.

Splitting too early gives you all the complexity of distributed systems with none of the benefits. You spend your time managing infrastructure instead of building product.
Our Take

At Qodors, we've seen more startups hurt by premature microservices than helped by them.

The right path is usually:

Start with a clean, modular monolith
Draw clear boundaries between business domains inside it
Extract a service only when you have a real reason — a piece that needs independent scaling, a team that needs independence, a component with different reliability needs

When you do split, split by domain, give each service its own data, and make them communicate loosely.

Microservices are a tool, not a trophy. Use them when the problem demands it — not because a blog post told you monoliths are dead.
Before You Split Your Next Service

Five questions to ask first:

Are you splitting by business domain or technical layer? Domain is right. Layer is a trap.
Will this service own its own data? If it shares a database, it's not independent.
Can it be deployed alone? If not, you've just added a network call.
Can it survive other services being down? Real services degrade gracefully.
Do you actually need this split? Or would a clean module in your monolith do the job?

Microservices aren't about having many services.

They're about having **independent **ones.

Get that wrong, and you've just made your monolith slower and harder to deploy.

Microservices #SoftwareArchitecture #DistributedSystems #SystemDesign #StartupCTO #TechLeadership #BackendDevelopment #SoftwareEngineering #QodorsEdge

Written by the team at Qodors — we help startups build architecture that actually scales. → www.qodors.com

Your API Design Is Why Integrations Take Forever

qodors — Tue, 02 Jun 2026 09:44:30 +0000

A developer wants to integrate with your API. You expect it to take two days.

Two weeks later, they're still fighting it.

Missing documentation. Inconsistent responses. No pagination. Cryptic error messages. Authentication that makes no sense.

Your API works. But working isn't the same as usable.

Bad API design doesn't just frustrate developers. It kills deals, delays launches, and quietly costs you customers who give up and find an alternative.
Why APIs Become a Nightmare

Most APIs aren't designed. They grow.

You build one endpoint. Then another. Then a feature needs a quick addition, so you bolt it on. Six months later, you have 40 endpoints that all behave differently.

One returns userId. Another returns user_id. A third returns id. Same data, three formats.

Errors come back as plain text sometimes, JSON other times. Status codes are random. A failed request returns 200 with an error message buried in the body.

Developers integrating with this don't read your mind. They read your responses. And your responses are chaos.
The 5 Fixes That Save Weeks

1. Consistent Naming and Structure

Pick a convention. Stick to it everywhere.

If you use snake_case, use it for every field, every endpoint, forever. If your list endpoints return { "data": [...] }, every list endpoint returns that exact shape.

Consistency means developers learn your API once, then predict the rest. Inconsistency means they check the docs for every single call.

2. Proper Error Responses

Errors are not an afterthought. They're half your API.

Every error needs a consistent structure:

json

{ "error": { "code": "INVALID_EMAIL", "message": "The email format is invalid", "field": "email" } }

Use correct HTTP status codes. 400 for bad input. 401 for auth failures. 404 for missing resources. 429 for rate limits. Don't return 200 with an error inside.

A developer should know what broke and how to fix it — without contacting your support team.

3. Pagination From Day One

That endpoint returning all records works fine with 50 rows. At 50,000 rows, it times out and crashes.

Build pagination into every list endpoint from the start. Cursor-based or offset-based, pick one.

GET /users?limit=20&cursor=eyJpZCI6MTAwfQ

Retrofitting pagination later means breaking every existing integration. Do it now.

4. Versioning Strategy

The day you change a response format, every integration breaks.

Version your API from the beginning:

/v1/users /v2/users

When you need breaking changes, ship v2 and keep v1 alive. Give developers time to migrate. Don't break production on a Tuesday afternoon.

5. Documentation That Actually Helps

A reference list of endpoints isn't documentation.

Real documentation has:

Working code examples in multiple languages
Real request and response samples
Authentication walkthroughs
Common error scenarios
A way to test calls live

If a developer can integrate without messaging you, your docs work. If your inbox fills with "how do I..." questions, they don't.
The Hidden Cost of Bad APIs

Every confusing endpoint is a support ticket.
Every missing example is a delayed integration.
Every breaking change without versioning is an angry customer.
Every inconsistent response is hours of debugging on someone else's side. Bad API design doesn't show up on your dashboard. It shows up in churn, slow sales cycles, and partners who quietly walk away. Our Take

At Qodors, we treat API design as product design. Because for developers, your API is your product.

A well-designed API gets integrated in hours. A bad one gets abandoned in weeks.

The difference isn't more features. It's consistency, clear errors, proper pagination, smart versioning, and documentation that respects the developer's time.

Most teams skip this because it's not glamorous. That's exactly why doing it well sets you apart.
If Your Integrations Take Too Long

Five questions to ask your team:

Is every endpoint consistent? Same naming, same response shape, same patterns.
Are your errors structured and clear? Right status codes, helpful messages, actionable details.
Does every list endpoint paginate? Or will it crash at scale?
Do you have a versioning strategy? Or does every change break someone?
Can a developer integrate without contacting you? That's the real documentation test.

Your API isn't just code. It's an experience.

Make it one developers actually want to use.

APIDesign #SoftwareEngineering #DeveloperExperience #BackendDevelopment #StartupCTO #TechLeadership #APIDevelopment #EngineeringBestPractices #QodorsEdge

Bottom CTA:
Written by the team at Qodors — we build APIs developers actually want to use. → www.qodors.com

AI Observability: Stop Flying Blind in Production

qodors — Wed, 27 May 2026 11:21:37 +0000

You shipped your AI feature three months ago. Users love it. Usage is growing.

But when someone asks "How's the AI performing?" — you have no idea.

Is it answering correctly? How often does it fail? Which queries cost the most? When response times spike, what's the cause?

Most teams can tell you their web server uptime down to the second. Ask them about their AI accuracy in production, and they just shrug.

That's a problem.
Why Traditional Monitoring Doesn't Work for AI

Your standard observability stack tracks HTTP status codes, response times, error rates. That works fine for regular APIs.

AI systems are different. A 200 response doesn't mean success. The model could return complete nonsense with perfect status codes.

Traditional metrics miss what actually matters:

Quality: Did the AI give a good answer or garbage?
Cost: Was that response worth the API bill?
Latency: Why did that query take 12 seconds?
Accuracy: Is the system getting better or worse over time?

You need AI-specific observability. Not just server monitoring with extra dashboards.
What AI Observability Actually Looks Like

1. Response Quality Scoring

Every AI response needs automatic quality assessment. Not manual review — that doesn't scale.

Set up scoring pipelines that check:

Relevance: Does the answer match the question?
Completeness: Did it address all parts of the query?
Safety: Any inappropriate or harmful content?
Consistency: Same question, similar answer?

Use a separate model to grade responses. GPT-4 judging GPT-3.5 outputs. Claude evaluating your custom model results. Cross-validation prevents bias.

2. Cost Per Interaction Tracking

Break down spending by feature, user segment, query type. Not just total monthly bills.

Which features burn the most tokens? Which user behaviors trigger expensive operations? When costs spike, which workflows drove it?

Track cost efficiency: dollars spent per successful interaction. If quality stays flat but costs double — something's broken.

3. Latency Breakdown

AI requests have multiple steps. Model inference, prompt processing, response formatting, any retrieval operations.

Don't just measure total response time. Measure each component. When things slow down, you need to know if it's the model, your preprocessing, or network issues.

4. Failure Classification

AI systems fail in unique ways. Model timeouts. Context window overflows. Safety filter blocks. Hallucination detection triggers.

Traditional error monitoring lumps these together. You need granular failure categories. What broke? Why? How often? Which failures matter most to users?

5. Quality Drift Detection

Models degrade over time. Data distribution shifts. User expectations evolve. Quality that was good six months ago might not be good today.

Set up regression detection. Compare current performance to historical baselines. Alert when accuracy drops below thresholds.
The Monitoring Stack That Works

This isn't one tool. It's an architecture.

Logging Layer: Capture everything. Input, output, model used, tokens consumed, processing time, quality scores. Structure it for analysis.

Real-time Dashboards: Quality metrics, cost trends, latency percentiles, failure rates. Not just pretty charts — actionable data.

Alerting System: Quality below threshold? Costs spiking? Response times degrading? Alert the right people with context.

Analysis Tools: Historical trends, A/B test results, user satisfaction correlation. What's working? What's not? Why?

Data Pipeline: Move logs to your data warehouse. Enable deeper analysis. Feed insights back into model improvements.
The Implementation Reality

Most teams skip this entirely. They ship the feature and hope for the best.

Others bolt on basic logging after problems surface. That's reactive firefighting, not observability.

Smart teams build monitoring from day one. Every AI request gets instrumented. Every response gets evaluated. Every failure gets categorized.

It takes discipline. Extra engineering time. More complex deploys.

But when something goes wrong at 2 AM — and it will — you'll know exactly what, why, and how to fix it.
The Questions Your Dashboard Should Answer

If your AI observability can't tell you this, it's incomplete:

Right now: Is our AI feature healthy or degraded?
This week: Are we getting better or worse results than last week?
This month: Which improvements had real impact on user satisfaction?
Cost analysis: Where are we overspending? What optimizations worked?
Quality trends: Are users getting better answers over time?

If you can't answer these questions with data — you're flying blind.
Our Take

At Qodors, we build observability into AI systems from the start. Not as an afterthought when things break.

Because shipping AI features is easy. Keeping them reliable, cost-effective, and improving over time — that's the hard part.

Most teams optimize for the demo. We optimize for production. That includes knowing when production isn't working.
If You're Running AI Features Without Proper Observability

Five things to implement this week:

**Start logging everything**. Input, output, cost, latency, quality scores. You can't improve what you don't measure.
**Set up automated quality assessment**. Use one model to grade another's responses. Scale manual review.
**Track cost per successful interaction**. Not just total bills. Where does money go for good vs bad outcomes?
**Define your quality metrics**. What makes a good AI response in your product? Measure that specifically.
**Build alerts for degradation**. Quality drops, costs spike, latency increases — know immediately.

Don't wait until your AI breaks in production to start measuring it.

Build the visibility layer now. Because the alternative is explaining to users why you didn't know your AI was broken.

AIObservability #AIMonitoring #ProductionAI #AIEngineering #StartupCTO #AIArchitecture #MLOps #TechLeadership #QodorsEdge

Written by the team at Qodors — we build observable AI systems, not black boxes. → www.qodors.com

LLM Costs Are Killing Your Startup. Here's Your Cost Optimization Playbook.

qodors — Fri, 22 May 2026 10:12:18 +0000

Picture this: You launched an AI writing tool six months ago. Growing fast. Users love it.

Then the bill comes. $14K from OpenAI. Last month it was $8K. The month before, $3K.

Every user interaction hits GPT-4. Every document generated. Every revision suggested. Every grammar check. Your AI costs are growing faster than your revenue.

This is happening to hundreds of AI startups right now.

Why Your LLM Bill Is Out of Control

Most teams treat API calls like they're free. Fire a request to GPT-4, get an answer, move on.

That works fine when you have 50 users. When you hit 5,000 users making 10 AI requests each per day — you're looking at 50,000 API calls. At current pricing, that's real money.

The hidden multiplier is repeat requests. Users ask the same questions. Generate similar content. Run identical workflows.

You're paying OpenAI to compute the same answers over and over.

The Cost Optimization Stack That Actually Works

Semantic Caching (The Biggest Win)

Regular caching looks for exact matches. "What is machine learning?" gets cached. "What is ML?" misses the cache entirely.

Semantic caching works differently. It converts questions into embeddings, then checks if a similar question was asked recently. If the embedding distance is close enough — serve the cached response.

Smart AI products implement this early. Within two weeks, cache hit rates typically reach 60%. Six out of ten requests never touch OpenAI.

Response Compression

Most teams send the full conversation history with every request. A 10-turn conversation becomes a 5,000-token context window.

Instead, summarize old context. Keep recent messages verbose, compress everything else into a 200-token summary. The model gets enough context to stay coherent without burning tokens on ancient chat history.

Model Tiering

Not every request needs GPT-4. Simple classification, basic Q&A, formatting tasks — GPT-3.5 or Claude Haiku handle these fine at 10x lower cost.

Build a routing layer. Intent classification happens first with a cheap model. Complex reasoning gets escalated to expensive models.

80% of requests can stay on the cheap tier. Quality barely changes.

Batch Processing

Individual API calls have overhead. Response time, connection setup, per-request pricing.

For non-real-time workflows — content generation, data processing, analysis — batch everything. OpenAI's batch API costs 50% less than real-time calls.

That background job that generates product descriptions? Perfect for batching.

Prompt Compression

Shorter prompts cost less. Every token counts.

Audit prompts regularly. Remove verbose examples. Cut unnecessary instructions. Use bullet points instead of paragraphs.

A 1,200-token system prompt can often compress to 400 tokens without losing functionality. That's 66% cost reduction on every call.

The Implementation Reality

This isn't plug-and-play. You need architecture.

Caching Layer: Redis or Postgres with vector similarity search. Not complicated, but it needs monitoring.

Routing Logic: A lightweight service that decides which model handles each request. Rules-based or ML-based classification.

Usage Monitoring: Track costs per feature, per user, per model. You can't optimize what you can't measure.

Fallback Handling: What happens when the cache fails? When the cheap model can't handle a request? When OpenAI is down?

The Numbers That Matter

From typical implementations across AI products:

• 60-80% cache hit rates on semantic caching after two weeks
• 70% cost reduction with proper model tiering
• 50% savings on batch-eligible workloads
• Overall reduction: 65-85% without feature cuts

The setup takes 2-4 weeks. The savings compound forever.

Our Take

Most startups can run production AI features for under $1,000/month. Even at scale. But you need the infrastructure layer that treats API calls like the expensive resource they are.

At Qodors , these optimization patterns are built from day one. Because watching your AI bill triple every month isn't a scaling problem. It's an architecture problem.

If You're Staring at a Five-Figure LLM Bill

Five questions to ask your team:

• Are you caching semantically similar requests? If not, you're burning 50-70% of your budget.
• Does every request really need GPT-4? Simple tasks should route to cheaper models automatically.
• Can any workflows be batched? Real-time isn't always necessary.
• How long are your prompts? Every unnecessary token adds up across millions of calls.
• Do you know your cost per feature? If you can't measure it, you can't fix it.

Your AI features don't need to cost enterprise money. They need enterprise architecture.

Build the cost layer. Don't let OpenAI pricing dictate your runway.

LLMCosts #AIOptimization #StartupFounders #OpenAI #CostEngineering #AIArchitecture #StartupCTO #TechDebt #QodorsEdge

Written by the team at Qodors — we build cost-efficient AI systems, not budget-burning demos. → www.qodors.com

AI Wrappers Are Dying. Here's What Replaces Them.

qodors — Tue, 19 May 2026 11:52:01 +0000

Remember when every other startup on Product Hunt was "ChatGPT but for X"?

That era is over.

We watched it happen in real time. A client came to us last year with an AI writing tool. Nice UI. Clean onboarding. Under the hood? A single OpenAI API call with a system prompt.

Three months later, OpenAI released custom GPTs. His entire product became a free feature overnight.

He's not alone.

What Happened to the Wrapper Economy

The playbook was simple. Take an LLM API. Wrap a UI around it. Add a login page and a Stripe subscription. Ship it.

For a while, it worked. Users didn't know how to use ChatGPT properly. They needed guided experiences. Wrappers filled that gap.

Then the gap closed.

OpenAI added custom instructions. Then custom GPTs. Then the GPT Store. Claude got Projects and system prompts that anyone can configure. Google shipped Gems.

Every feature a wrapper offered became a native capability of the platform it depended on.

The moat was never the UI. It was the user's ignorance. And that's not a moat. That's a countdown timer.

Why Most Wrappers Can't Survive

Three reasons. All fatal.

** 1.Zero switching cost.**

If your product is a prompt and an API call, the user can rebuild it in 10 minutes. With custom GPTs, they don't even need to code. They just describe what they want and get roughly the same thing your paid product offers.

Your $29/month subscription is competing with free.

** 2. Platform risk is absolute.**

You don't control the model. You don't control the pricing. You don't control the features.

OpenAI raises API costs? Your margins disappear. They ship a feature that overlaps with yours? Your value proposition disappears. They change their terms of service? Your business model disappears.

Building a company entirely dependent on another company's API with zero contractual protection — that's not a startup. That's a hope.

** 3.No defensible IP.**

What do you actually own? A prompt template? A UI skin? A landing page?

Investors are asking this question now. "What happens if OpenAI builds this?" If the honest answer is "we're done" — that's your answer.

What's Actually Working Instead

The AI products that survive share common traits. None of them are wrappers.

They own their data layer.

The product's value isn't the AI call. It's the proprietary data the AI operates on.

A legal tech startup we worked with built a contract analysis tool. The AI is important, sure. But the real value is their database of 50,000+ annotated legal clauses built over 18 months. No custom GPT replaces that.

Your data is your moat. Not your prompt.

They solve workflow problems, not text problems.

Wrappers generate text. Surviving products automate entire processes.

There's a difference between "summarize this document" and "read this document, extract the 12 fields we need, validate against our rules, flag exceptions, update the database, and notify the right person."

The first one is a wrapper. The second one is a product.

They use AI as infrastructure, not interface.

In the best AI products, users don't even know AI is involved. It runs in the background. Scoring, classifying, routing, deciding. The user sees results. Not a chat window.

The moment your product feels like "talking to ChatGPT with extra steps" — you've already lost.

They're model-agnostic.

Smart teams build abstraction layers. They can swap GPT-4 for Claude for Gemini for an open-source model without rewriting their product.

Because they know what we all know — today's best model is tomorrow's commodity. The product has to stand without any specific model propping it up.

The Hard Truth About "AI Startups"

Most AI startups aren't AI companies. They're UI companies with an API key.

And that's fine for a side project. But if you're raising money, hiring a team, and betting your next two years on it — you need more than a wrapper.

You need proprietary data. Or proprietary workflow logic. Or proprietary domain expertise baked into the system. Ideally all three.

The AI layer should be replaceable. Your product shouldn't be.

Our Take

At Qodors (www.qodors.com), we've had founders come to us with wrapper ideas almost every week this past year. Our first question is always the same:

"What happens when the model provider ships this as a native feature?"

If there's no good answer, we don't build it. We help them find the version of the idea that actually survives.

That usually means going deeper. Building the data pipeline. Designing the workflow engine. Creating the integration layer that connects AI to the messy, specific, real-world systems their users already depend on.

That's harder than wrapping an API. It takes longer. Costs more upfront.

But it's still standing 18 months later. The wrappers aren't.

If You're Building an AI Product Right Now

Honest questions to sit with:

• Strip out the AI completely. Does your product still solve a problem? If not, you don't have a product. You have a demo.
• Can a user replicate your core value with a custom GPT in 15 minutes? If yes, your pricing model has an expiration date.
• What data do you own that nobody else has? If the answer is nothing — start there. The data strategy matters more than the model strategy.
• Are you building on one model or building model-agnostic? Single model dependency is single point of failure.
• Is AI your product or your infrastructure? The best answer is infrastructure. Always.

The wrapper era taught us something useful. There's massive demand for AI-powered tools. People will pay for products that save them time and reduce decisions.

But they won't pay for a middleman between them and ChatGPT. Not when ChatGPT keeps getting better at being ChatGPT.

Build the thing the model can't become. That's your product.

Written by the team at Qodors — an AI-first software studio that builds products, not wrappers. → www.qodors.com

AIStartups #AIWrappers #ProductStrategy #StartupFounders #AIIntegration #BuildSmart #TechStrategy #OpenAI #QodorsEdge