Skip to content
Rafael Aslanian

Mobile and app development, built for the ward

Works offlineand keeps the trail

Rafael Aslanian

Signal comes and goes on a ward. The app collects anyway, then syncs when the connection returns. So the queue on the device is part of the study record. Two people edit the same visit offline, and the app has to hold both versions and record which arrived first. Whether it counts as a medical device is worth settling before anybody draws a screen.

Book a 15-minute call

Send the details below. I'll reply by email to arrange a time.

London, UK · Available for new projects

The usual bottlenecks

What actually slows medtech and clinical research teams

  1. The record keeps the value and loses the history

    A record that updates in place keeps the current value and loses the one before it. Good Clinical Practice wants the old value, who changed it, when, and why. Adding that after the study opens means going back through backups to work out what the field used to say.

  2. Consent is easy to take and hard to withdraw

    The form captures it once and stores a yes. A withdrawal has to reach the analysis extract, the copy the statistician pulled for the interim look, and the partner who already has a dashboard. Capturing consent is a field in a database, and acting on its removal is a job that touches everything downstream.

  3. Every site connects in a different way

    One trust offers an HL7 v2 feed, another a FHIR endpoint that only answers from inside the network, and a third sends a spreadsheet somebody types into REDCap by hand. Each new site restarts the DSPT and DTAC conversation from the top, with a different information governance lead.

  4. Pseudonymised still points back at a person

    Strip the DICOM header and the patient's name can still be burnt into the pixels. The free-text box a clinician typed into carries more than every tick box on the form. The key linking a study ID to a patient has to live somewhere, and where it lives is the question.

How I do it

mobile and app development

Most of what gets asked for as an app is a website that works properly on a phone. You will hear that first. Where the platform genuinely needs a native shell, for push, camera or offline work, it gets one. The web build and the app share one TypeScript core, so the domain model and the API layer are written once, by one person. A rule changes in one place, and both builds inherit it.

A written answer on whether to build
Before anything gets built you get the honest read on whether an app is the right answer, with the mobile web version priced next to it. If the answer is no, the document says no.
One codebase behind the web and the apps
The website, the iOS app and the Android app are built from the same code and the same API layer, so a change to the rules is written once. No second copy quietly disagrees with the first.
Getting through App Store and Play review
Signing keys, privacy forms, the age rating and screenshots at every size go in under your own store accounts. If a build gets knocked back, getting it through is my job and not yours.
See the full service
Selected work

Selected projects

Products I built and open-source projects I maintain. Open a project to see the work for yourself.

  • 01
    2026

    Dr Flavia Pretti Aslanian

    Healthcare · Practice site

    A bilingual dermatology website for a practice in Harley Street and Wimbledon

    Dr Flavia's new dermatology landing page, with consultation booking and treatment navigation

    A new landing page guides patients to medical, aesthetic and surgical care. The practice edits its own content, and staff have a password-protected dictation tool in the same app.

    • Next.js
    • Sanity CMS
    • Tailwind v4
    • Radix
    • Motion
    • ISR
    • Railway
    • Cloudflare

    Design · Build · Deploy

    • 84 published English and Portuguese routes
    • 72 treatment pages with clinic-editable content
    • Custom before/after comparison UI
    • Internal clinician dictation tool
  • 02
    2026

    Continuum

    Web3 · DeFi protocol

    A Solana DeFi protocol for 24/7 synthetic exposure to real-world assets

    The Continuum page as it is published

    Deposit USDC, mint matched long and short tokens at NAV, sell the leg you don't want. A constant-product invariant keeps the pair redeemable back to the deposit.

    • Rust
    • Anchor
    • Solana
    • TypeScript
    • Pyth
    • Next.js
    • Bun
    • Railway

    Pre-mainnet. Devnet markets, audits pending.

    Protocol · Frontend · Infra

    • 5 Solana smart contracts in Rust
    • 8 synthetic markets on devnet
    • 4-state oracle risk machine
    • Volatility-scaled fee curve
See 4 more projects
  • 03
    2025 →

    Delta Xi

    E-commerce · Brand

    A mathematics apparel brand on a storefront I wrote from scratch

    Delta Xi's website hero, showing the front of a white T-shirt with a neural network diagram.

    I built the cart, checkout, product recommendations, affiliate programme and support desk, and run the infrastructure myself.

    • Next.js
    • React Server Components
    • Stripe
    • Auth.js
    • Tailwind
    • Umami
    • Chatwoot
    • Cloudflare

    Founder · Engineer · Operator

    • Custom checkout on Stripe + Klarna
    • Server-rendered recommendation engine
    • Self-hosted analytics and live chat
    • 50+ STEM explainers driving organic search
  • 04
    2026

    Dray

    AI tools · Product website

    A product website for keeping project context across AI agents

    The Dray page as it is published

    An editorial landing page introduces shared project context, shows illustrative agent workflows and explains setup and privacy ahead of beta.

      Beta coming soon. The public demos illustrate the workflow; they are not live agent connections.

      Design · Build

      • Interactive agent-linking illustration
      • Project-context walkthrough
      • Setup and privacy guidance
    • 05
      2026

      Tallylamp

      Open source · Browser infrastructure

      A browser for AI agents that you can watch and take over

      Tallylamp's public website, with an interactive demo of an agent handing browser control to a person.

      I built the browser service, dashboard, MCP server and public website. Agents use Chrome on your server while you watch the same browser live. Take control to sign in, then hand it back; saved profiles carry between sessions.

      • TypeScript
      • Next.js
      • Chrome
      • MCP
      • SQLite
      • Docker
      • Railway

      Public site at tallylamp.dev. The browser service and dashboard are self-hosted.

      Creator · Engineer · Maintainer

      • Live viewing and explicit human handoff
      • Separate agent permissions and reusable profiles
      • MIT licensed, with a Railway deploy template
    • 06
      2025 →

      CarClout

      SaaS · AI content engine

      A subscription app that turns a phone photo of a car into something worth posting

      The CarClout page as it is published

      Upload a photo, pick a template, get the edit back a moment later. Thirteen AI models sit behind a metered credit ledger, next to a layer editor, a post scheduler and a live chat room.

      • Next.js
      • SurrealDB
      • Auth.js
      • Stripe
      • fal.ai
      • Cloudflare R2
      • Stream.io
      • Railway

      Engineering · Infra · SEO

      • 724 generated landing pages, all live
      • 128 API routes behind one app
      • 13 AI models on a metered credit ledger
      • Instagram posting, scheduling and analytics
    Also on the books

    One runs on the client's own domain and one is internal to theirs, so there is nothing here of mine to show you.

    The rest

    Not everything is public. A fair amount of the work sits in private repositories I cannot hand you a link to. Ask, and I will walk you through it.

    Ask to see more
    Process

    How a project runs

    1. 01Before code

      Scope

      One call, then a written spec. What it does, what it deliberately does not do, and what milestone one is. You sign that off before I write a line.

    2. 02Early

      First deploy

      A narrow slice that actually works, running where it belongs. A URL you can open, a build on your phone, a job on your own servers. Real data, real hosting, no placeholder screens.

    3. 03Ongoing

      Build in the open

      Deploys land as the thing fills in, not in one drop at the end. You watch it happen. And you get to change your mind while changing it is still cheap.

    4. 04Handover

      Yours to run

      The product runs in your accounts, with the domain, hosting and documentation under your control. Source-code transfer is quoted separately; we agree what is included during scoping.

    Rafael Aslanian photographed against bamboo
    Rafael AslanianLondon, UK
    About

    Rafael Aslanian

    I got my hands on a computer at 6 and never really stopped.

    Now it is decentralised finance, tokenising real-world assets and topological deep learning, then building whatever those turn into. Continuum came out of that. So did Delta Xi (δξ, an infinitesimal change in a random variable).

    Bossa nova and MPB were always on at home, so I sang before I played anything. Guitar and piano came later, then jazz.

    Based
    London, UK
    Languages
    English, Portuguese; intermediate Spanish and Chinese
    Focus
    Web3, DeFi, real-world asset tokenisation
    Also
    Music
    Contact

    Have an idea? Tell me.

    A paragraph is plenty. I read every one myself and reply within one business day. If it isn't something I can do well, I will say so and point you somewhere better.

    Reply within one business day

    One thing I don't do

    Need the audience too?

    I can build the thing. Getting people to notice it is a separate job, and not mine. For that I work with Nytforge, who film, edit and put the work in front of a local audience. They are strongest with automotive and local businesses.

    Talk to Nytforge