Application performance optimization
Find what is slow, prove it, and make it fast.
Application performance optimization is finding where a web or mobile app spends its time, then removing the slow parts: queries, queues, caching, and blocking work on the hot path. Acasa Labs does it from measurements, not guesses. On a private trading platform we built, every stage of the hot path is timed, and market-data decode runs in microseconds.
The problem
The app was fast at launch. Then the customers arrived.
A page that loaded in a second with a hundred users takes six with ten thousand. A report times out. The mobile app spins while the API waits on a query nobody has looked at since the first sprint. Users do not file bug reports about this; they leave. And guessing at the fix wastes weeks, because the slow part is rarely where the team thinks it is.
What we build
- 01
Measure before touching anything
Timing on the slow paths, query plans for the database, and queue depth for background work, so the fix goes where the time actually goes.
- 02
Faster data access
Indexes, rewritten queries, fewer round trips, and pagination that does not load the whole table.
- 03
Nothing blocking the hot path
Slow work moved to queues and workers, so a user's request returns as soon as it can and the rest happens behind it.
- 04
Caching that actually caches
Responses, images, and computed results cached at the right layer, with URLs and headers that browsers and CDNs will honour.
From production
Performance work from systems we run.
Time every stage
Options trading platformLatency on the trading platform is instrumented across 12 stages with exact percentile reservoirs. In tape replay, market-data decode runs at 2.5 µs at p50 and 8 µs at p99.
Keep blocking work off the loop
Options trading platformMarket-data decode runs on its own thread and is handed to the engine loop thread-safely, so nothing blocking ever sits on the engine loop. The dashboard publisher is bounded and drops when full instead of slowing trading.
URLs a CDN can cache
KraftrKraftr's signed image URLs stay byte-identical within a day, so browsers and CDNs actually cache them instead of fetching every image again.
Read less to answer faster
SigmaCPMSigmaCPM retrieves the candidate pages of a tender before extraction, so the model reads the right pages instead of the whole package.
Honest trade-offs
When the fix is not code
Sometimes the database is simply too small, or the server is in the wrong region for your users, and a configuration change beats a week of optimization. Sometimes the slow feature is one nobody uses, and the right move is to remove it. We tell you which it is after measuring, before we start rewriting.
What we reach for
- Prometheus, Grafana
- Sentry performance tracing
- Postgres query plans, indexes
- Redis, BullMQ, Postgres job queues
- Cloudflare CDN caching
- Load testing
Proof
Shipped, not pitched.
01Client work
Options trading platform
Microsecond market-data handling for index options, with risk checks that never sleep.
A private trading platform for index options on an Indian exchange: tick capture, research and backtesting, paper and live execution, and a control dashboard. Built for a client's internal use; details are anonymized.
Trading engine · Realtime gateway · Web dashboard
02Our product
Kraftr
One flat-lay photo becomes catalog-ready 4K on-model imagery.
An AI catalog studio for fashion and jewelry brands. Upload one flat-lay or hanger shot per SKU and get on-model imagery at up to 4K, in ten aspect ratios, sized for Amazon, Myntra, Flipkart, and Shopify.
Web · iOS · Android
03Our product
SigmaCPM
Construction project management where AI reads the tender and shows its work.
One project record for civil contractors, from tender to closeout: bids, contracts, RFIs, vendor quotes, and drawings. The AI pulls line items and bond terms out of tender PDFs and cites the page for every value.
Web · API · Chrome extension
Questions
Performance optimization questions we get asked.
Can you speed up an app you did not build?
Yes. We start by measuring it in production or in a copy of production, find the few places where most of the time goes, and fix those first. You get a written list of what we found before we change anything.
How do you know a change made it faster?
We measure the same paths before and after, at the same percentiles. A change that does not move the numbers does not ship.
Is the problem usually the database?
Often, but not always. Slow pages also come from work done during the request that belongs in a background job, from images that are never cached, and from frontends that load far more than they show.
Will you need to rewrite our app?
Rarely. Most performance problems are a handful of hot spots. A rewrite is only worth discussing when the measurements show the architecture itself is the limit.
Do you optimize mobile apps too?
Yes: slow screens, heavy API calls, and work that should be saved on the device. Most mobile slowness is actually the backend, so we measure both.
Application performance optimization
Tell us what feels slow.
Send us the page, the screen, or the report that users complain about. We will tell you how we would measure it and what we would look at first.