Indonesia's 2026 Funding Winter: An Engineer's Cost Playbook

In June a colleague forwarded me a screenshot. Indonesian startups had raised USD 50.7 million across eleven equity rounds so far in 2026, down about 70 percent on the same stretch of 2025. The number did what numbers like that do: it went round three group chats before lunch, and by the afternoon two people had asked me whether this was a bad year to be an engineer here.

I build ERP and internal systems for Indonesian companies, so my work sits on the other side of that statistic, with the firms that buy software rather than the ones that raise money to build it. This post is about what I actually changed when capital got expensive, which turned out to be a list of technical decisions rather than a career plan. It starts by reading the funding number more carefully than I did in June.

The number I reacted to in June had reversed by August

The June reading was real. Tracxn's Indonesia page reported USD 50.7 million raised across eleven equity rounds through June 2026, against USD 170 million across twenty-six rounds in the same period of 2025, a fall of just over 70 percent. Nothing about it was misreported and nobody was spinning anything.

I opened the same page on 4 September 2026 and it said the opposite. Through August 2026 it reports USD 365 million raised across seventeen equity rounds, against USD 208 million across forty-one rounds through August 2025, a rise of 75.6 percent. Six additional rounds had landed in roughly two months and carried more than USD 300 million between them.

Both sentences are honest readings of the same series, and that is the whole point. Eleven observations is not a distribution, it is a handful of cheques, and one large round outweighs every small one combined. The round count actually fell year on year while the total rose, which describes a market placing fewer and larger bets rather than a market with no money in it. If two months of ordinary deal flow can reverse your reaction to a number, the number was never load-bearing enough to plan against.

Eleven rounds is not a trend, and equity is not the economy

There is a second error underneath the first, and it survives even when the series settles down. Equity funding measures one financing channel. It does not measure demand for software. The same Tracxn page reports 37,927 Indonesian companies tracked and 2,609 that have ever raised funding, which is fewer than one in fourteen. The other thirteen are companies with customers, and companies with customers still need systems built, integrated and kept running. That is where most of the work I have done actually came from:

• Distributors replacing spreadsheets with an ERP that has to reconcile stock across several warehouses
• Clinics, salons and workshops buying scheduling and billing they can operate without an IT department
• Manufacturers wiring tax and e-invoicing into systems that already work and must keep working
• Anyone whose payment flow has to speak QRIS, virtual account and card at the same time

None of that demand is priced by a funding round. It is priced by whether the buyer's own revenue is growing, which is a different question with a different answer, and it is the question you should be tracking if you work where I work.

What a high cost of capital does to a technical decision

Cost of capital is the return an investment has to clear before it is worth making. When it is near zero almost everything clears, and when it rises the bar moves up through a whole class of decisions that were previously invisible. In engineering terms, the payback period stops being a slide in someone else's deck and becomes the unit of account for your architecture.

The practical form of that is blunt. A managed service that saves two engineer-days a month is no longer competing against the alternative of building it, it is competing against not having it at all. So is the second staging environment, and so is the platform work that only pays back at a headcount the plan no longer contains. AWS's Cost Optimization pillar lists five design principles, and two of them do most of the work here: adopt a consumption model, and analyse and attribute expenditure. You cannot re-price what you cannot see, and most teams cannot see it, because the bill arrives as one number with no owner attached.

The decisions that get re-priced first

I went through our own stack with one question per line item. What does this cost per month, and what would it cost to not have it. The clearest hit was a managed queue we were using for exactly one thing, retrying failed document exports, at a volume a single Postgres table handles without noticing. PostgreSQL documents SKIP LOCKED as part of the SELECT locking clause, and it turns an ordinary table into a work queue that several workers can drain safely.

-- A work queue in the database you already pay for.
-- SKIP LOCKED is the whole trick: a worker takes the first row nobody
-- else has locked instead of blocking behind them.
CREATE TABLE export_job (
  id           bigserial PRIMARY KEY,
  payload      jsonb        NOT NULL,
  run_after    timestamptz  NOT NULL DEFAULT now(),
  attempts     int          NOT NULL DEFAULT 0,
  locked_until timestamptz
);

-- Without this the claim query sorts the whole table on every poll.
CREATE INDEX export_job_ready ON export_job (run_after);

-- One worker, one batch, one round trip.
WITH claimed AS (
  SELECT id
    FROM export_job
   WHERE run_after <= now()
     AND (locked_until IS NULL OR locked_until < now())
   ORDER BY run_after
   FOR UPDATE SKIP LOCKED    -- do not queue behind another worker
   LIMIT 20
)
UPDATE export_job j
   SET locked_until = now() + interval '5 minutes',
       attempts     = j.attempts + 1
  FROM claimed c
 WHERE j.id = c.id
RETURNING j.id, j.payload;

That removed a line from the bill and added about forty lines of SQL that anyone on the team can read. Two details matter more than the syntax. The claim and the lock happen in one statement, so a worker cannot crash between choosing a row and marking it, and locked_until is a lease rather than a flag, so a worker that dies releases its rows by expiry instead of stranding them.

It is not universally the right trade. At high volume a managed queue earns its money back, and I would not move a large fan-out workload into the database that also serves the application. But at our volume the managed service was buying convenience we had already built around, and that is the shape of most of these decisions: not wrong when they were made, just made under a different interest rate.

Reading runway from the inside, without gossip

You do not need anyone's cap table to know whether money is getting tighter where you work. The operational signals arrive weeks before any announcement and every one of them is visible from an ordinary seat.

1. Renewals stop being automatic. A tool that renewed silently for three years suddenly needs a written justification, and someone asks what it would cost to leave.
2. Infrastructure consolidates. Two accounts become one, a region is retired, and the phrase shared cluster appears in a design document that never mentioned it before.
3. Hiring pauses without being announced. A requisition stays open, the interview loop quietly stops being scheduled, and nobody says the word freeze.
4. The nice-to-have project is not cancelled, it is deferred. It moves to next quarter, then into a backlog nobody grooms, and then it is simply not mentioned.
5. Approvals get slower in one direction only. Anything that adds spend needs three signatures, and anything that reduces spend is approved the same week.

None of these on its own means the company is in trouble, and every one of them is also just good housekeeping. The fifth signal is the one that tells you something, because it points at where the organisation's attention is. When the only fast decisions are the ones that reduce spend, cost work is the work that gets read, and that is where your effort becomes legible to people who have never seen your code.

The work that survives a cost-cutting cycle

Every role I have seen protected in a squeeze was attached to either revenue or cost, and could show which. Keeping the payment integration working is revenue. Making an existing system measurably cheaper to run is cost. Keeping the thing up is both. Framework fashion is neither, and a rewrite that has not shipped is the hardest artefact in the building to defend, because it consumes on the cost side and contributes on neither.

Being attached to cost means answering where the time goes with a query rather than an opinion. The database is usually the cheapest place to start, because pg_stat_statements has been collecting the answer for months and nobody has asked it.

-- Where does the database actually spend its time?
-- pg_stat_statements must be in shared_preload_libraries with the server
-- restarted; CREATE EXTENSION on its own collects nothing at all.
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT
  round(total_exec_time::numeric / 1000, 1) AS total_seconds,
  calls,
  round(mean_exec_time::numeric, 2)         AS mean_ms,
  shared_blks_read,
  left(query, 90)                           AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 15;

-- Rows aggregate by normalised query text, so one row is one SHAPE of
-- query and not one execution. Reset before a measurement window or you
-- will rank a migration that ran once in March.
SELECT pg_stat_statements_reset();

Expect the top row to be dull. It is usually a count query behind a dashboard, or an N plus one hiding in a list endpoint, and the fix is more often deletion than tuning. That is a good outcome to be able to describe out loud: you removed a cost, you can name the exact query, and the graph moved on a date you can point at.

Leverage that is not tied to one employer

The uncomfortable part of a cost-cutting cycle is that most of your evidence lives inside a private repository you can lose access to on a Friday. Everything you know how to do is real, and none of it is visible from outside the building. Fixing that is unglamorous and takes an evening rather than a strategy.

Start with an inventory of what you have actually shipped, generated from the repositories rather than from memory, because memory flattens three years of work into a job title. The script below is deliberately crude: it counts commits, bounds the period with real dates, and names the directories you touched most, which are the subsystems you genuinely know.

#!/usr/bin/env bash
# An inventory of shipped work, built from the repos and not from memory.
# Run it while you still have access. Keep the output, not the clone.
# No set -e here on purpose: a repo with no commits of yours makes grep
# exit non-zero, and that must skip the repo rather than abort the loop.

ME="[email protected]"        # every address you have ever committed under

for repo in ~/work/*/; do
  [ -d "$repo/.git" ] || continue
  name=$(basename "$repo")

  # First and last commit bound the period you can honestly claim.
  span=$(git -C "$repo" log --author="$ME" --reverse --date=short \
           --pretty=%ad | sed -n '1p;$p' | tr '\n' ' ')

  count=$(git -C "$repo" log --author="$ME" --oneline | wc -l | tr -d ' ')

  # The directories you touched most ARE the subsystems you actually know.
  areas=$(git -C "$repo" log --author="$ME" --name-only --pretty=format: \
           | grep -v '^$' | cut -d/ -f1-2 | sort | uniq -c \
           | sort -rn | head -3 | awk '{ print $2 }' | paste -sd, -)

  printf '%-24s %5s commits  %s %s\n' "$name" "$count" "$span" "$areas"
done

Then convert three of those rows into something a stranger can read without an NDA. A post about the specific problem, a small library extracted from the part that was general, or a public repository showing the pattern with the client's data removed. Three finished artefacts read better than ten half-finished ones, and the reading is done by people who will not ask you follow-up questions.

The other half of this is people rather than artefacts, and it works the same way. A colleague who has watched you debug something under pressure is a stronger reference than any profile, and that relationship has to exist before you need it. The version of this that fails is the one that starts on the day the news breaks.

The counterweight, stated honestly

Almost none of this is downturn advice. Knowing what your infrastructure costs, being able to name the query that burns the most time, keeping an inventory of what you have shipped and holding relationships outside your employer were all correct in 2021 and will still be correct when the rounds are large again. A funding winter does not create the discipline, it removes the slack that let you skip it.

The asymmetry worth saying out loud is that a downturn is a bad time to be complacent and a fine time to be useful. The work that got easier to justify, making an existing system faster, smaller and less likely to page someone at two in the morning, is work most engineers find satisfying anyway. Very little about my week changed. What changed is that the reasons are now easy to explain to someone who does not write code.

So I stopped forecasting. When the next funding number is forwarded to me I will read it, note the date attached to it, and check whether it moved because of a trend or because of one cheque. Then I will go back to the list that actually responds to my effort: what this system costs to run, what it earns, and whether anyone outside this building can tell that I built it.