Skip to content
About

One person,start to finish.

I’m Ionuț. I started out doing what most people do: taking on whatever came in and learning in public. Three years later I’ve shipped apps to the App Store, written a native component library that runs in production, and built sites for clients in three countries.

The work I’m proudest of is the boring part. Not the first screen, but the release process, the error tracking, and the migration that carried a user’s entire scan history across sign-up without losing a single row. That is most of the distance between a demo and something people actually rely on.

The person who designed the data model is the person who submits the build. Nothing falls into the gap between two people who each assumed the other had it, because there is no gap.

Ionuț Sandu
Languages
Romanian, English
Status
Open now

“Most developers hand you a folder of code. I hand you something in the store.”

Design handoff, backend, payments, review submission, and the marketing site that points at it. One person, start to finish.

Honestly

What I’m good at,and what I’m not.

Where I’m genuinely useful

  • Shipping end to endIdea, architecture, backend, app, store submission and the marketing site around it, with no handoff in the middle where things get lost.
  • Native modules and platform edgesSwift modules, the New Architecture, camera and vision pipelines. The parts most React Native developers hand off.
  • Taking over a messy codebaseReading someone else’s work, telling you honestly what is salvageable, and finishing it.
  • Writing things downScopes, READMEs, handover docs. Whoever opens the project in a year can follow it without a phone call.

What I’m not: the person to build a brand identity from scratch, and not a shop that runs ten projects at once.

How I work

You see it every week.Not a demo at the end.

  1. 01

    We agree the scope first.

    A written scope and a fixed quote before any money moves. If I don't think I'm the right person, I'll say so.

  2. 02

    You see it weekly.

    A build in your hands every week, not a demo at the end. You change direction while it is still cheap. If you would rather only have the written update, say so and that is what you get.

  3. 03

    I build it to last.

    TypeScript strict, tests on the logic that matters, error tracking wired in. Open it in a year and it still makes sense.

  4. 04

    I hand it over completely.

    The code, every account, where it is hosted and the notes on how it works, on the day it ships rather than months later.

WHAT THE WEEKS LOOK LIKEA TYPICAL MOBILE BUILD
  1. WEEK 1

    Scope, repo, environments

    A written scope, the repository in your account, CI green.

  2. WEEK 2

    Data model and auth

    First build in your hands. Installable, not a staging link. It is there to prove the thing works; the design lands across the two weeks after it.

  3. WEEK 3–4

    Core features, one build a week

    You change direction while changing direction is still cheap.

  4. WEEK 5

    Hardening

    Error tracking, tests on the logic that matters, anything an extra added.

  5. WEEK 6

    Submission and handover

    Both store reviews, then repository, accounts, deployment and docs.

Every build lands on your device. There is never a link to chase.

Not all of it is building. A stretch of it is store review, which runs at Apple’s pace rather than mine, and the rest moves at the speed you come back on each build. The projects that finish in four weeks are the ones where somebody looks at Friday’s build on Monday.

Taking on new projects

Tell me what you’re building.A written scope and a fixed quote before any money moves.

I reply to everything within one working day. If I’m not the right person for it, I’ll tell you straight away rather than three weeks in.