Most transformation projects fail for the same reason: they replace everything at once, and the people doing the work have no path from the old way to the new one. The system is technically correct and practically abandoned.

We start by mapping what actually happens — not the documented process, the real one, including the spreadsheet someone maintains privately because the official system cannot do the thing they need. That spreadsheet is a requirement, not a workaround to be scolded out of existence.

Then we sequence. A phase that removes one painful step and leaves the rest alone earns trust for the next phase. Big-bang replacement spends all its credibility on day one and has none left when something breaks.

Where this fits

This is the right engagement when you have processes running on paper, spreadsheets, or a system nobody likes, and you need them to become software without stopping the business while it happens.

Some decisions are cheap to change and some are not. Which database you use is usually recoverable. Where you draw the boundary between two systems, who owns which data, and what you decided to build instead of buy — those set the shape of everything after them.

Architecture work here means getting the expensive decisions right and leaving the cheap ones to the team who will live with the code. A document that specifies every class is not architecture; it is a bottleneck with a title.

Integration boundaries

Most of the difficulty in a real system is not inside a service — it is between services, and between organisations. We define those contracts explicitly: what crosses the boundary, in what shape, who is responsible when it fails, and how the other side finds out.

Technical due diligence

If you are acquiring a system, inheriting one, or deciding whether to keep investing in it, we will read it and tell you what we find — including when the answer is that it is fine and you should stop worrying about it.

We build native iOS in Swift and native Android in Kotlin, and use cross-platform where the app genuinely does not need platform-specific behaviour. That last judgement is part of the work — picking cross-platform to save money and then fighting the framework for six months saves nothing.

Through submission, not up to it

Store submission is where mobile projects quietly stall. Privacy declarations have to match what the app actually does. Policy URLs have to resolve. A keyboard extension gets scrutinised harder than a to-do list app. Review rejections arrive with terse messages that assume you already know the rule being cited.

We have shipped through this repeatedly, including in categories reviewers treat with suspicion. The store-facing policy pages on this very site are generated from a typed registry for exactly that reason — those URLs must never 404 during a review.

After launch

The first version teaches you what you were wrong about. Engagements include the release that responds to that, not just the one that gets you approved.

An MVP is not a smaller version of the full product. It is the smallest thing that produces a real answer to the riskiest question you have. Those are different objects, and building the first when you needed the second is the most common way a first version wastes a year.

So the scoping conversation is mostly about what to leave out, and why. If everything is essential, nothing has been decided yet, and building will not decide it for you.

Bootstrapped constraints are a feature

NpKs is bootstrapped and has shipped its own products with no outside funding. That shapes how we scope: we are used to budgets that are real, timelines that cannot slip indefinitely, and the discipline of shipping something that works before the money runs out. If you are in the same position, we understand the constraint from the inside.

This is the work very few teams anywhere do properly, and it is where we are genuinely differentiated.

Khmer is not a script you can treat as "Latin with different glyphs". A single visual unit — a grapheme cluster — can be several codepoints, with subscript consonants (coeng) stacked below the base and vowel signs placed around it. Get the model wrong and the symptoms are specific and familiar to any Khmer speaker: a backspace that deletes half a character, a text field that truncates mid-cluster, a line break in the middle of a word, sorting that puts words in an order no dictionary would recognise.

What we work on

• Unicode correctness — grapheme-cluster-aware cursor movement, deletion, selection, and truncation
• NiDA standard compliance — the Cambodian national standard for Khmer encoding and keyboard layout
• Input methods — iOS keyboard extensions and Android IMEs, including fitting the full Khmer character set onto a phone-sized layout
• Typography — font selection and fallback that keeps coeng stacking intact, in apps and on the web

An honest scope

We are not claiming to be the only people who can do this. We are saying that most teams do it by accident, discover the problems from user complaints, and patch symptoms rather than the model. We start from the model.

If your product serves Cambodian users and its Khmer support was an afterthought, an assessment will usually find real, fixable problems quickly.

Sometimes what a team needs is not more delivery capacity. It is one person who has seen this decision before and will say plainly what they would do and why.

Fractional CTO

For a company that needs senior technical judgement but not a full-time executive: hiring decisions, architecture direction, vendor assessment, and being the person who can tell the board what is actually true about the technology.

Architecture review

An outside read on a design before you commit to it. The useful version of this is not a list of everything that could theoretically be better — it is identifying the two or three choices that will be expensive to reverse, and pressure-testing those.

When the answer is "you are fine"

We will say that. An advisory engagement that manufactures problems to justify itself is worse than no engagement, and it is obvious to everyone within a month.