SoftwareArchitect.ID

Writing code got cheap. Deciding what to build didn't.

Every architecture decision is a trade-off. We make them with you, out loud: what you gain, what you give up, and when to revisit it.

Book a discovery call Send us a brief

Tell us what you're deciding. If we're not the right fit, we'll say so.

Led by the architect behind the product platforms at Xendit and Veriff: payments, ledgers, API gateways and reliability.

ideafirst releasereal customersbuild for scalewe're with you at every stage

Where we usually come in

Three situations we see most. Each one is a trade-off before it's a technical problem.

Shipping an MVP fast

You have the idea and the funding, and need to launch soon without rebuilding it all in a year.

Speed now, against foundations you can't add later.

  • The smallest scope that proves the business
  • What has to be right from day one: data, money, access
  • Who to hire first, and when they can run it alone

A new payment gateway had to be built from scratch, with no engineering team yet.

We scoped the MVP (double-entry ledger, authorisation, routing between payment providers, public API, dashboard). Hired a tech lead and four engineers, and set a pre-launch checklist with load and end-to-end testing.

The MVP was delivered, and the team was mentored until it ran without us.

Something deep is wrong

A ledger, a data flow or a core service is slow, wrong or breaking under load.

A quick fix, against a fix that holds.

  • What is actually failing, and since when
  • Bigger machines, or a change in design
  • What each fix costs your team to run afterwards

Finlens was building a ledger and wanted to avoid the production problems ledgers hit at scale.

We reviewed their design against the failures we'd seen in ledgers at scale, and ran weekly sessions with their core engineers.

Their team knew which problems to design out before launch, and which to watch for after.

Multi-year programs

Several teams, a system that has to change while it keeps running.

Moving forward, against keeping everything running.

  • Where the architecture should be in two to three years
  • The order of changes, so each step pays off on its own
  • Which teams move first

Ad-Ins needed to split a monolith into microservices without losing control of it.

We analysed the monolith to choose a decomposition strategy, recommended the distributed-system patterns to use, and set a short, medium and long-term plan.

Their engineers moved through it with regular consulting sessions, and kept the plan as their own.

How an engagement runs

Small steps. You can stop after any of them and keep what you paid for.

  1. 1

    Discovery call

    What you're deciding, and whether we're the right fit.

  2. 2

    Review

    The options and what each one costs, written down for you to keep.

  3. 3

    Build together

    With your team, or the team we help you hire.

  4. 4

    Hand over

    Until your team runs it without us.

Pricing is agreed after the call, per engagement.

Try our thinking on your own system

Free, and it runs in your browser. Nothing you enter is sent anywhere.

Production-readiness check

15 quick questions. See which risks you carry by shipping as-is.

Run the check

Who leads your work

Portrait of Iman Tumorang

Iman Tumorang

Founding architect

Staff engineer on Veriff's product platform and software architect at Xendit before that: API gateways, server-driven UI, reliability, ledgers and billing. Iman leads every engagement.

Creator of go-clean-arch, faker and dbresolver, Go open-source projects with 11k+ GitHub stars.

Resume (opens in a new tab) imantumorang.com (opens in a new tab) LinkedIn (opens in a new tab) GitHub (opens in a new tab)

Read before we talk

How we think about architecture, in public. Notes of SoftwareArchitect.ID is our newsletter on Substack: architecture notes, research and discussions.

Subscribe on Substack (opens in a new tab) Read all notes (opens in a new tab)

Also from us: engineers.id (opens in a new tab), a curated feed of software architecture reading.

Tell us what you're deciding.

If we're not the right fit, we'll say so.

Book a discovery call
Send us a brief

What to include

  • What you've built, or what you're deciding
  • A link, if it's live
  • What it's built with ("not sure" is fine)
  • Does it handle payments or sensitive data?
  • How many users today
  • When you want to launch, or decide

[email protected]

Don't send passwords, keys or code. We'll agree on safe access after we talk.