Loading page content
Services
Most engagements are one of these, or two of them in sequence. Each is described by the problem it solves, because that is what you are actually buying.
You need an iOS and Android app that feels native, and you do not want to fund two separate teams to get it.
I build React Native applications the way they need to be built for production: CLI-based rather than locked into a managed runtime, with native modules written when JavaScript is the wrong tool, platform differences handled deliberately, and a release process that gets through App Store and Play review without drama. Reanimated for interaction, Vision Camera when the camera is core to the product, and a state architecture chosen to match how the data actually behaves.
Typically includes
You need one engineer who can take a product from database schema to shipped interface without handoffs going missing.
When a small team splits a product across specialists, the gaps between them become the bugs. I work across the whole stack — React and Next.js on the front, Node, Laravel or FastAPI behind it, MySQL or PostgreSQL underneath — so decisions on either side of the API are made with the other side in mind. Fewer handoffs, fewer assumptions, and no argument about whose layer the problem lives in.
Typically includes
You are about to commit a team to a codebase for the next two years and want the structural decisions to be right.
Navigation and state structure, offline and sync strategy, data caching, module boundaries, native integration points, environment and build configuration, release and versioning. I produce a plan your team can build against, with the reasoning written down — including what I deliberately chose not to do and what would need to change if the product goes in a different direction.
Typically includes
The app works, mostly — but it crashes, it is slow, and every change takes three times longer than it should.
Taking over someone else's codebase is a skill of its own. I start by reading and measuring rather than rewriting: crash clusters, slow screens, dependency risk, the places where the same logic exists in four versions. Then a sequenced plan that fixes the bleeding first and restructures second, so the product keeps shipping while it gets healthier. A rewrite is occasionally the right answer, and I will tell you honestly if it is — but it usually is not.
Typically includes
You need something real in front of users quickly, without building something you will have to throw away.
MVP does not have to mean disposable. I scope hard, cut features rather than quality, and keep the architecture simple enough to build quickly but structured enough that the parts you keep do not need rewriting. You get a product you can put in front of users and investors, plus an honest list of what was deferred and what it will cost to pick up later.
Typically includes
Your app needs a backend that is secure, predictable and does not fall over when usage grows.
Clear resource design, consistent error semantics, validation at the boundary, authentication and role-based authorisation, pagination and filtering that hold up at volume, and migrations that can be run safely against live data. I design the database schema around real access patterns rather than a diagram that looks tidy, and I index for the queries that will actually run.
Typically includes
Your product depends on live data, live location or live conversation, and it has to work on a bad connection.
Real-time features fail in the gaps: the tunnel, the backgrounded app, the expired token, the duplicate event after a reconnect. I build the transport layer around those cases first — connection lifecycle, backoff, message ordering, idempotency, presence and state reconciliation — then the feature on top. Voice and video via Agora, native call handling through CallKeep, sockets for live data and tracking.
Typically includes
You are charging money through the app stores and cannot afford to get entitlement state wrong.
Store subscriptions are deceptively hard: purchases restore on a new device, receipts validate late, trials convert while the app is closed, refunds happen server-side, and a user who paid must never see a paywall. I implement RevenueCat or direct store integration with the server as the source of truth for entitlement, webhook handling for lifecycle events, and a paywall that degrades safely when the network is unavailable.
Typically includes
You need external services wired in properly — not glued on until they break in production.
Every integration is a dependency you do not control. I wrap them behind an interface you own, handle their failure modes explicitly, keep credentials server-side, and make sure swapping a vendor later is a contained change rather than an archaeology project. Firebase, RevenueCat, Agora, payment providers, analytics, authentication and whatever the product actually needs.
Typically includes
Four areas where the work is genuinely difficult, and where getting it wrong is expensive to undo later.
Navigation structure, state boundaries, offline behaviour, native module strategy, and a release process that does not depend on one person remembering the steps.
API design, authentication, authorisation and role-based access, background jobs, and the database schema that all of it rests on.
Sockets, presence, calling, payments, subscriptions and third-party services that need to keep working when the network does not.
Profiling slow screens, cutting startup time, fixing crash clusters, and reducing the technical debt that makes every change expensive.
A process is only useful if it has outputs you can point at. Here are mine.
Product goals, users, constraints and the business reason this is being built. I ask the uncomfortable questions early, while they are still cheap.
Scope, risks, open questions
Data model, API surface, state boundaries, native requirements and the decisions that would be expensive to reverse later.
Technical plan, schema, milestones
Vertical slices that can be demoed, not horizontal layers that only work at the end. Reviewed, typed and documented as it goes.
Working increments, weekly builds
Real devices, weak networks, tests around the parts that would hurt if they broke, and profiling before anything is called finished.
Test coverage where it counts, profiles
Store submission, staged rollout, crash and error monitoring, and a rollback path that exists before it is needed.
Production release, monitoring
What real usage reveals is usually different from what was assumed. Iterate on evidence, and pay down whatever the deadline forced.
Iteration plan, debt paid down
If something here is not answered, ask me directly — a short question by email is always fine.
Mostly React Native apps that are already in production and are now slow, crashing, or hard to release — plus full-stack product work where the mobile app and the backend need to be designed together. If your app has real users and a real problem, that is the shape of thing I am best at.
Both. But an existing app with a specific problem is where I add the most, because nine years of production experience is worth more when something is already broken than when nothing has been built yet.
A call, then a short written scope. For anything sizeable I would rather start with a fixed-price audit — a week, ending in a document that says what is wrong, what it would take to fix, and in what order. It is low risk for you, and you own the document whether or not you continue with me.
It depends on the scope, so I quote the project rather than an hourly rate — hourly billing turns speed and experience into an argument against me and makes the conversation about timesheets instead of results. Tell me what you are trying to fix and I will tell you honestly whether it is a week or a quarter, before either of us commits.
I work remotely with teams across European and US time zones and keep several hours of overlap with whichever one you are in. Reviews, releases and anything that needs a conversation are scheduled inside that overlap rather than left to asynchronous guessing.
You do. Everything I write for you is yours, delivered in your repository as I go rather than in one drop at the end. You should never be in a position where the work exists only on my machine.
Because the agreements that work was delivered under do not allow me to name the clients or use their screenshots, and I am not going to break them to make a portfolio look better. The role, the decisions and the stack are all real, every image on this site is my own artwork, and I am happy to walk through any of it on a call.
I will say so in the first reply, and tell you what I would look for instead. That costs me a project occasionally and it is still the right trade — I would rather turn something down than take it on badly.
Engagement
Not sure which of these you need?
That is a normal place to start. Describe the situation and I will tell you what I think the actual problem is — including if it is not one I should be solving.