Mustafa Dualeh

SHEET 01 / MUSTAFA DUALEH / ASIA-PACIFIC · UTC+8

MVPs, mobile apps and AI features.
Built to hold up.

FIG. 1.1 Real output of Tinkr Doodles: a figurine generated from a child's drawing, in its exact four-colour print plan. 45 × 140 × 70 mm.

I design and ship software for startups and small teams: a first version, a mobile app, or one AI feature that works in production. I spent eight years shipping Android and web products in Japan (2017–2025): at Nissan, at Daimler Trucks Asia, and as the sole Android developer of the Smooz browser (100,000 downloads). Today I build with AI coding agents: one writes, another reviews, tests must pass, and I approve every merge.

Email me about your project Read the Tinkr case study Hire me part-time

Not sure where to start? A paid scoping sprint (USD 600, 3–5 days) gives you a feature list, data model and fixed quote you keep either way. Start with a scoping sprint Opens your email app. I reply within one working day with questions and a suggested first milestone.

Services Rev. 2026-10 · SVC-01–03

What I can build for you

Three fixed-scope offers, each with a written plan, a weekly demo and a handover your team can maintain.

  1. SVC-01 · 4–8 weeks

    MVP build

    For founders and small businesses with a validated idea who need a working first version, as a web app or a mobile app.

    • A paid scoping sprint first (USD 600, 3–5 days): feature list and data model before any code
    • Web app (React) or Android app (Kotlin), or Flutter for both platforms
    • Accounts, database and API; Stripe payments and transactional email (admin panel in the larger package)
    • Tests on the money and data paths, CI/CD, store release where relevant, and a handover guide

    From USD 4,500

    one core workflow, web or Android, 4⁠–⁠5 weeks; with admin panel and operations USD 8,500, 6⁠–⁠8 weeks; Flutter for both platforms quoted after scoping

    Proof: Tinkr Doodles, from photo upload to Stripe checkout, designed and shipped to private beta. Case study Track record: eight years of Android at Nissan (connected-car apps, Android Automotive SDK, Flutter) and as sole Android developer of a startup browser that reached 100,000 downloads.

  2. SVC-02 · 1–4 weeks

    AI feature in production

    For teams who want one useful AI feature in an existing product, without runaway costs or unpredictable output.

    • Claude or OpenAI behind your backend, never in the browser
    • Answers come back in a fixed format your app can rely on
    • If the model fails or stalls, your product keeps working; abuse protection and a daily spend cap stop surprise bills
    • Accuracy measured on your own data before launch, not assumed

    USD 900

    one-week prototype; production from USD 2,500, 2⁠–⁠3 weeks

    Proof: Every Doodles drawing is screened by a vision model whose output is schema-checked and fails closed, under a daily spend cap. Case study

  3. SVC-03 · 3 days–4 weeks

    Fixes, performance and improvements

    For products that already exist and need to get better: bugs, slow screens, upgrades, integrations and the features that keep getting postponed.

    • Bug fixes with a regression test for each one
    • Performance and stability work, on web and Android
    • Upgrades and migrations: SDK and framework versions, Java to Kotlin, dependency clean-ups
    • Integrations, including Stripe payments and third-party APIs

    USD 600

    3⁠–⁠5 day audit with a written report; fixed-scope work from USD 1,500, or hourly

    Proof: Tinkr's checkout re-checks Stripe before an order changes, with a recovery path if a webhook never arrives. Case study Track record: introduced unit testing to a production Android codebase at Nissan.

Ongoing work

  • Maintain ~40 h/month · USD 2,200
  • Build ~70 h/month · USD 3,600
  • Part-time team member ~100 h/month · USD 4,800

Billed monthly, weekly written update, 30 days' notice. Also available for Android and Kotlin maintenance. I work remotely from the Asia-Pacific time zone (UTC+8).

Hire me part-time (10–25 h/week)

Doodles Rev. 2026-10 · FIG. 3.1–3.5

Featured work: Tinkr Doodles

A parent photographs a child's drawing. A few minutes later they can turn a 3D figurine of it, choose the colours and order a print, which Tinkr is designed to route to an independent local maker. One of the apps I built on Tinkr, my startup.

  1. Doodles landing screen on a phone, headed 'From crayon to keepsake.'

    Start

  2. Upload screen with options to take a photo or choose one from the library.

    Add the drawing

  3. Progress screen reading 'Making the magic' while the 3D model is generated.

    Generate the model

  4. 3D preview of a four-colour figurine of a girl with pigtails, with size and colour options.

    Preview, size and colours

  5. The same generated figurine seen from behind: black pigtails tied with red bands, a purple top, red shorts and purple shoes.

    The model, as printed 4 materials · 48,250 triangles · 243 KB Turn it at the top of the page ↑

FIG. 3.1–3.5 Local build in demo mode. Step 4 and the model are the same real generation; the model is shown in the print file's filament colours.

Under the hood

  • Every upload is screened by a vision model before anything is generated
  • Drawing to 3D model through an image-to-3D provider, with automatic fallback and a daily budget
  • Colours reduced to up to four printable filaments and written as a multicolour print file
  • The card is held at checkout and designed to be charged only when a local maker accepts the job
  • Passwordless sign-in, bot protection and an augmented-reality preview on phones
Read the Tinkr case study

Hiring managers and clients can request the full technical version.

Product
Tinkr Doodles
Role
Founder & technical lead
Stack
React, three.js / model-viewer, Cloudflare Workers, Postgres, Stripe
AI
Claude vision screening, image-to-3D generation
Status
Pre-launch · private beta
Print plan
Medium print, 45 × 140 × 70 mm, from the file in FIG. 1.1
SlotColourTriangles
1 Purple 15,089
2 Orange 12,833
3 Black 13,243
4 Red 7,085
Platform Rev. 2026-10 · FIG. 4.1–4.2

Built as a platform

Doodles is one app on Tinkr. The same API runs MakerChip and the hosted checkout, and is designed for partners who want to send print jobs into the provider network from their own products.

Apps
Tinkr DoodlesMakerChipCheckout Partner apps
3 first-party apps
each app has its own registered keys and checkout settings
Platform
Tinkr APIQuotes and ordersPaymentsSigned webhooks
one API for every app
jobs are matched by country, materials and capacity
Network
Independent print providersCloud slicingProvider payouts
payouts in trial

App registry

Every app, first-party or partner, is registered with its own keys, allowed origins and checkout return address, and can be paused on its own without touching the others.

Partner API

Sandbox and live keys, quotes and orders, a hosted checkout handoff, audience-filtered OpenAPI docs and signed webhooks with retries.

Developer tools

A TypeScript SDK, a sandbox that steps orders through every stage, and an AI build brief partners paste into their own coding agent.

Partner hub docs page with an AI build brief to copy into a coding agent and a TypeScript SDK download.
FIG. 4.1 Partner hub: TypeScript SDK and an AI build brief for coding agents. Test data.
Partner webhook endpoints list showing subscribed events, delivery attempts and status.
FIG. 4.2 Webhook endpoints with signed deliveries and retry limits. Example data.

Pre-launch: the partner API is built and documented, with no external partners live yet.

Experience 2013–2026

Experience

Connected-car apps for a global carmaker, internal tools for a truck manufacturer, the Smooz Android browser, and now my own platform. B.A. Computer Science, York University, Toronto.

  1. 2026–now

    Founder & technical lead

    Tinkr (Tinkr App Ltd, UK) · Remote

    • Pre-launch 3D-printing platform: API, four React apps, cloud slicing, Stripe payments and provider payouts (in trial).
    • Defined the product and architecture, and directed AI coding agents: one writes, another reviews, tests and CI must pass, and I approve the merge.

    Status Pre-launch, private beta

  2. 2020–2025

    Android engineer

    Nissan Motor Corporation · Tokyo

    • Built a camera-based Digital Driver's Guide prototype with TensorFlow Lite transfer learning, ML Kit and CameraX.
    • Shipped features for the Nissan Connect Android app and worked with the Android Automotive Car SDK. Introduced unit testing and contributed to the consolidated Flutter app.

    Stack Kotlin, Jetpack, Flutter, TF Lite

  3. 2018–2020

    Full-stack developer

    Daimler Trucks Asia (FUSO) · Kawasaki

    • Built internal Kotlin/Spring Boot and React applications: a quiz platform, truck-driver tracking, and the web front end of a bus-tracking proof of concept later used by staff and clients.
    • Taught a three-month introductory programming course in Kotlin to non-developers.

    Stack Spring Boot, Kotlin, React

  4. 2017–2018

    Lead Android engineer

    Astool Inc. · Tokyo

    • Sole Android developer of the Smooz mobile browser. Migrated it from Java to Kotlin and set it up so part-time developers could take it over.

    Result 100,000 downloads, 4.5 stars in three months (app since discontinued)

  5. 2013–2017

    Earlier roles

    Computec Japan · York University

    • Systems engineering, database administration and IT support in Tokyo. Web development and PL/SQL reporting for York University while studying.
Process Rev. 2026-10

How I work

AI tools changed how quickly I can build. They didn't change what makes software trustworthy: clear scope, review, tests and honest status updates.

  1. Prototype the risky part first

    I start with whatever could sink the project, usually the data model, the payment flow or the AI call. You get a clickable version within the first week or two.

  2. AI-assisted, with a paper trail

    I work with coding agents such as Claude Code and Codex the way a lead works with a team. On client work every change is scoped, reviewed by a second agent, covered by tests, and I test it against the acceptance criteria before it merges.

  3. Product decisions in writing

    I ask who pays, what has to be true on day one, and what can wait. You get a short decision log, so the reasons behind a choice are still there in six months.

  4. Integrations that assume failure

    Stripe, payout providers, email, AI APIs and cloud jobs all fail in their own ways. I treat every webhook as untrusted, make every write idempotent, and check external state before acting on it.

  5. Tests where the money is

    Automated tests cover the paths that move money or change data, and deploys are gated in CI. I would rather ship a smaller feature that works than a bigger one that needs a hotfix.

  6. A weekly written update

    What shipped, what's next and what I need from you, plus a demo link. I'm async-first from UTC+8, with calls 15:00–19:00 UTC+8 (08:00–12:00 London).

Contact Rev. 2026-10

Have something to build?

A useful first email includes

  • What you want to build or fix, in a few sentences
  • Who uses it and what "done" looks like for you
  • Your timeline and rough budget range
  • Links to anything that exists already: designs, repo, live site

Remote, from Asia-Pacific (UTC+8). Available to travel for short on-site periods when a project needs it. I reply within one working day.

Elsewhere