SoftwareArchitect.ID

You built something people want. Let's get it ready for them.

A fast build got you to a working product. Before real customers and real money go through it, we review it with you and fix what matters, in the right order.

Send us your project brief Book a call

Run the free readiness check ↓

prototypeproduction

What we look at before launch

The things that are easy to miss when you're building fast, in plain words.

  • Keys and passwords

    Kept out of places anyone can read

  • Who can see what

    Each user sees only their own data

  • Payments

    No double charges, no missed ones

  • Backups

    You can get your data back

  • Busy days

    It stays up when lots of people arrive

  • Knowing when it breaks

    You find out before your customers tell you

  • Releasing changes

    Updates without taking it down

  • Monthly costs

    No surprise cloud bills

What findings look like

Typical examples, not client data

Fix before launch

  • Secret keys readable in the browser
  • Any logged-in user can open another user's records
  • No backup that has ever been restored

Can wait, with a date

  • Admin pages are slow: revisit at a few thousand users
  • No automated tests yet: add them before the second developer joins

Is it ready for real customers?

15 quick questions in 4 topics. About 3 minutes.

No one gets all of these right before launch. "Not sure" is a fine answer: it's what a review finds out.

Keys and access

Are your secret keys (for payments, the database or AI) only on your server, and not in app code people can see?
Why this matters

Anyone can read browser code. A leaked payment or AI key can be used to spend your money.

If a logged-in user changes an ID in a link, do they still only see their own data?
Why this matters

This is the most common way one customer sees another's data.

Does your database itself stop one user reading another user's records?
Why this matters

Without it, one mistake in the app exposes every user's records.

Do sign-ins use a ready-made login service, rather than code you wrote yourself?
Why this matters

Login is easy to get subtly wrong, and attackers try it first.

Is there a limit on how often someone can log in, sign up or run costly actions?
Why this matters

Unlimited sign-ups and logins invite abuse and surprise bills.

Payments and bills

Does your server confirm each payment with the payment provider, instead of trusting the app?
Why this matters

Anything the browser says can be faked, including 'payment succeeded'.

If a customer double-clicks "pay", or a payment notice arrives twice, are they charged only once?
Why this matters

Retries happen. Without protection, customers get charged twice.

Do you know your monthly cloud and AI bill, and get a warning before it jumps?
Why this matters

Cloud and AI costs can grow quietly until the invoice arrives.

When something breaks

Is your data backed up automatically, and have you tried restoring a backup?
Why this matters

A backup you've never restored is a guess, not a backup.

Do you get a message when the app breaks or goes down?
Why this matters

Otherwise your customers are your monitoring.

When a user reports a problem, can you look up what happened?
Why this matters

Without logs, every bug report starts with guessing.

Can you try changes somewhere other than the live app your customers use?
Why this matters

Testing changes where customers are means customers find the bugs.

Can you undo a bad update within minutes?
Why this matters

Bad releases happen. What matters is how fast you can undo one.

Data you take in and keep

Is everything users enter checked on your server, not only in the app's screens?
Why this matters

Checks in the browser can be skipped; only the server's checks count.

Do you know what personal data you keep, and could you delete one user's data if asked?
Why this matters

Customers and laws will ask, and you'll need an answer.

Everything stays in your browser. Nothing is sent or stored.

A production-readiness review

We go through your product and its setup with you. You get a written report in plain language: what's risky, what to fix first, and what can safely wait.

Then, if you want, we fix it with you or your developer, launch it, and hand it over.

It isn't a penetration test or a security certification.

How it works

  1. 1

    Call or brief

    What you've built and when you want to launch

  2. 2

    Review

    Read-only access to your code and setup

  3. 3

    Walkthrough

    We go through the report together

  4. 4

    Fix and launch

    Optional, with you or your developer

Is this for you?

A good fit

  • A working product
  • Real users or payments coming soon
  • A launch or fundraising date

Not yet

  • An idea without a product yet: book a call about building an MVP instead

Who does the review

Led by the architect behind the product platforms at Xendit and Veriff (payments, ledgers, API gateways and reliability), who has also taken a payment product from MVP to production with a pre-launch checklist including load testing.

Questions founders ask

I'm not technical. Is that a problem?

No. The report is written for you, and we walk you through it.

Will we have to rebuild everything?

Usually not. Sometimes one part needs rebuilding. If so, we'll say which part, why, and what it costs to wait.

What access do you need?

Read-only to start. Nothing changes without you.

What does it cost?

It depends on the size of the product. We'll give you a price after the call.

Tell us what you've built.

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

Book a discovery call
Send us your project 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.