Skip to content
NEUROVOICE — Neuro Tech Voice
Start free

Custom Mobile Applications

Any app, for iOS and Android. We already run the half you don’t see.

iOS and Android apps, designed, built and published. For your customers or your own team, in any field and however complex, we build yours: first a prototype you tap through on your own phone, then the app for both platforms, in whatever technology the product calls for, published to both stores under your name. The half you don’t see — sign-in, payments, messages and live connections — already runs every day on this platform, our own product for AI phone agents. Our team holds 20+ personal Claude accreditations from Anthropic, and our company holds startup grants from Cartesia and ElevenLabs.

Call us about a buildTap through the sample

+40 774 566 367 · No form: a build starts with a phone call.

What an app talks to, running here

Sign-in
email · Google
Accounts, checked on the server
Email and password or Google, a reset link by email, and an account deleted from settings
API
80+ API routes
The requests an app sends
From accounts and payments to live calls; systems calling in prove who they are with a signature or a secret
Payments
7 Stripe event types
Stripe and SmartBill
Checkout, a customer portal, and fiscal invoices, each issued only after a check for one on record
Messages
8 account emails
Emails and texts nobody sends by hand
Emails as things happen, and five kinds of booking text in 14 languages, each reminder sent once

Counted from the repository by the site’s own tests. A plus means at least.

See what it talks to

What we build

Any app your business needs, for your customers or your own team. Not just phone agents.

For your customers

  • Booking, loyalty and membership apps
  • Shops, marketplaces and delivery
  • Apps for patients, students and members
  • Money apps: payments, points, wallets

For your own team

  • Field-service and inspection apps
  • Delivery-driver and warehouse apps
  • Staff schedules, time sheets and shifts
  • Internal tools, in everyone’s pocket

With AI or live features

  • Assistants that answer inside the app
  • Photos and documents read by AI
  • Live chat, maps and tracking
  • Voice and calls, as on this platform

In any field: retail, hospitality, healthcare, education, finance, logistics, construction, fitness, real estate — or one this list doesn’t name.

Tap through the sample

One app on iOS and Android, and what it talks to

A sample booking app, drawn for this page. Switch it between iOS and Android and follow one customer through five steps, from signing in to a reminder on the lock screen. Each step lights up the parts of this platform it talks to.

Sample app · no code behind it

Step 5 of 5: Later, on the lock screen

iOS: a large title, a tab bar, and sheets that slide up from the bottom.

Ringed buttons move you through the app.

Step 5 of 5 · Reminder

Later, a daily job finds the bookings coming up and sends each reminder once.

Talks to

  • Daily jobs
  • Database
  • Push
Every part, in full

Two apps or one?

One design, fitted to each platform, and built in whichever technology the product needs or you prefer: chosen with you, never imposed.

  • Native, for each

    Swift and SwiftUI · Kotlin and Jetpack Compose

    An app for iPhone and an app for Android, each in its platform’s own language: the most direct way to everything the phone can do.

  • One codebase for both

    React Native with Expo · Flutter

    One set of code for both phones, so a change reaches both stores in the same release, with each platform’s own code where a screen needs it.

  • The code you already have

    Whatever it’s written in

    We read it first, then say plainly whether to carry on from it or start again, and why.

Whichever it is, the prototype, the server and the path through both stores stay the same.

The journey, in words

  1. Sign in — Welcome back

    The phone sends only what was typed; the server decides who is signing in.

    Talks to: Sign-in, Database.

  2. Choose — Book a time

    Free times come from the server, and stay current while the customer looks.

    Talks to: API, Database, Live connection.

  3. Pay — Confirm and pay

    The card goes to the payment provider; the booking is confirmed once the money arrives.

    Talks to: Payments, API, Database.

  4. Booked — You’re booked

    Once it’s booked, the app asks about notifications, each platform in its own way.

    Talks to: API, Database, Push.

  5. Reminder — Later, on the lock screen

    Allow
    Later, a daily job finds the bookings coming up and sends each reminder once.
    Talks to: Daily jobs, Database, Push.
    Don’t allow
    With notifications off, the reminder comes by text, the way this platform sends its own.
    Talks to: Daily jobs, Database, Emails and texts.

Platform

  • iOS: a large title, a tab bar, and sheets that slide up from the bottom.
  • Android: a top app bar, a navigation bar, and the system’s back gesture.

The reminder text, word for word

Reminder from Your app: your appointment is on [the time]. Need to change it? Just call us. Reply STOP to opt out.

Every part the phone talks to runs on this platform except push, which is built for yours.

Your kind of app

Whatever the app does, and whoever it’s for

Six of the many kinds of app we build, to show the pattern. Pick one and who uses it: each sample shows its first screens, what it asks of the phone, and which of the parts behind it already run on this platform.

Kind of app

Who uses it

Sample · Bookings · Your customers

Book a time, pay a deposit, get reminded

People booking a salon, a clinic, a class or a court

Its first screens

  1. Services
  2. Choose a time
  3. Pay a deposit
  4. My bookings
  5. Reminder

What it asks of the phone

  • Notifications, Needs it

    Reminders, so fewer people miss their slot

  • Calendar, Needs it

    The booking added to their own calendar

  • The phone’s wallet, Often

    A card saved on the phone, for the deposit

  • Face or fingerprint, Often

    Quick sign-in for regulars

What runs behind it

  • Sign-in: Runs here
  • API: Runs here
  • Database: Runs here
  • Payments: Runs here
  • Files: Not used
  • Live connection: Runs here
  • Daily jobs: Runs here
  • Emails and texts: Runs here
  • Push: Built for yours

Every part, and where it runs here

With AI
AI suggests the next free time that suits them
What makes it hard
Two people tapping the last free time at once, and a reminder that must go out exactly once.
The store rule it meets
What the app sells decides who takes the payment

All twelve samples, in words

Bookings

  • Your customers

    Book a time, pay a deposit, get reminded

    People booking a salon, a clinic, a class or a court

    Its first screens
    1. Services
    2. Choose a time
    3. Pay a deposit
    4. My bookings
    5. Reminder.
    What it asks of the phone
    • Notifications, Needs it: Reminders, so fewer people miss their slot.
    • Calendar, Needs it: The booking added to their own calendar.
    • The phone’s wallet, Often: A card saved on the phone, for the deposit.
    • Face or fingerprint, Often: Quick sign-in for regulars.
    What runs behind it
    Runs here: Sign-in, API, Database, Payments, Live connection, Daily jobs, Emails and texts.
    Built for yours: Push.
    Not used: Files.
    With AI
    AI suggests the next free time that suits them.
    What makes it hard
    Two people tapping the last free time at once, and a reminder that must go out exactly once.
    The store rule it meets
    What the app sells decides who takes the payment

  • Your staff

    The day’s bookings, at a glance

    The people who take the bookings

    Its first screens
    1. Today
    2. A booking
    3. Check someone in
    4. Block time off
    5. Messages.
    What it asks of the phone
    • Notifications, Needs it: A new or moved booking, the moment it changes.
    • Works offline, Needs it: Notes kept when the signal drops.
    • Scanning codes, Often: Checking someone in from a code.
    • Face or fingerprint, Often: A quick sign-in between appointments.
    What runs behind it
    Runs here: Sign-in, API, Database, Live connection, Emails and texts.
    Built for yours: Push.
    Not used: Payments, Files, Daily jobs.
    With AI
    AI drafts a reply to a message, for a person to send.
    What makes it hard
    A change at the front desk showing on every phone at once, and notes written with no signal kept safe.
    The store rule it meets
    The reviewer gets a way in

Shops

  • Your customers

    Browse, buy and follow the order

    Shoppers, on a shop or a marketplace

    Its first screens
    1. Browse
    2. A product
    3. Basket
    4. Pay
    5. On its way.
    What it asks of the phone
    • Notifications, Needs it: Every change to the order, as it happens.
    • The phone’s wallet, Needs it: Paying with a card saved on the phone.
    • Scanning codes, Often: Vouchers and codes, in the shop.
    • Location, Often: The delivery address, from where they are.
    What runs behind it
    Runs here: Sign-in, API, Database, Payments, Files, Daily jobs, Emails and texts.
    Built for yours: Push.
    Not used: Live connection.
    With AI
    AI search that understands what they meant.
    What makes it hard
    Stock that stays right when two people buy the last one, and refunds that reach the right card.
    The store rule it meets
    What the app sells decides who takes the payment

  • Your staff

    Sell, pack and ship from the phone

    Sellers and the people who pack the orders

    Its first screens
    1. New orders
    2. Add a product
    3. Pack an order
    4. Ship it
    5. Payouts.
    What it asks of the phone
    • Camera, Needs it: Product photos, taken where the product is.
    • Scanning codes, Needs it: Each item scanned as it’s packed.
    • Notifications, Needs it: A new order, the moment it’s paid.
    • Works offline, Often: Packing lists that work in the stockroom.
    What runs behind it
    Runs here: Sign-in, API, Database, Payments, Files, Emails and texts.
    Built for yours: Push.
    Not used: Live connection, Daily jobs.
    With AI
    AI writes a first description from the product’s photo.
    What makes it hard
    Paying many sellers correctly from one checkout, and never shipping an order twice.
    The store rule it meets
    The reviewer gets a way in

Delivery and field work

  • Your customers

    Order it, and watch it arrive

    Customers of a delivery or collection service

    Its first screens
    1. Order
    2. Pay
    3. On its way
    4. Driver chat
    5. Delivered.
    What it asks of the phone
    • Location, Needs it: The drop-off point, set from where they are.
    • Live updates, Needs it: The map moving while they watch.
    • Notifications, Needs it: A note when it’s nearly there.
    • The phone’s wallet, Often: Paying with a card saved on the phone.
    What runs behind it
    Runs here: Sign-in, API, Database, Payments, Live connection, Emails and texts.
    Built for yours: Push.
    Not used: Files, Daily jobs.
    With AI
    AI answers ‘where is my order?’ from the tracking itself.
    What makes it hard
    A map that moves smoothly while the phone’s signal comes and goes.
    The store rule it meets
    What the app sells decides who takes the payment

  • Your staff

    The route, the job and the proof

    Drivers and technicians out on the road

    Its first screens
    1. Today’s jobs
    2. Route
    3. Checklist
    4. Photo, signature
    5. Done.
    What it asks of the phone
    • Location, Needs it: The route to each job.
    • Location, phone locked, Needs it: Following the route with the phone locked.
    • Camera, Needs it: Photos of the work, before and after.
    • Works offline, Needs it: Working in a basement, then catching up.
    What runs behind it
    Runs here: Sign-in, API, Database, Files, Live connection, Daily jobs.
    Not used: Payments, Emails and texts, Push.
    With AI
    AI reads a meter, a label or a delivery note from a photo.
    What makes it hard
    A route that keeps going with the phone locked, and a battery that lasts the shift.
    The store rule it meets
    A privacy policy, in the store and in the app

Health and care

  • Your customers

    Appointments, messages and results in one place

    Patients of a clinic or a care service

    Its first screens
    1. Sign in
    2. Appointments
    3. Messages
    4. Documents
    5. Reminder.
    What it asks of the phone
    • Face or fingerprint, Needs it: Records opened only by the person they’re for.
    • Notifications, Needs it: Reminders for appointments and medicine.
    • Calendar, Often: Appointments in their own calendar.
    • Files, Often: Letters and results to keep.
    What runs behind it
    Runs here: Sign-in, API, Database, Files, Daily jobs, Emails and texts.
    Built for yours: Push.
    Not used: Payments, Live connection.
    With AI
    AI answers questions from the clinic’s own information.
    What makes it hard
    Data that must stay in one region, and a sign-in strong enough for what it protects.
    The store rule it meets
    A privacy policy, in the store and in the app

  • Your staff

    Visits, notes and forms on the go

    Carers and clinicians between visits

    Its first screens
    1. Today’s visits
    2. A visit
    3. Notes
    4. Forms
    5. Hand-over.
    What it asks of the phone
    • Works offline, Needs it: Notes that are never lost with no signal.
    • Face or fingerprint, Needs it: A quick, strong sign-in between visits.
    • Location, Often: The way to the next visit.
    • Camera, Often: A photo for the record, when it’s needed.
    What runs behind it
    Runs here: Sign-in, API, Database, Files, Daily jobs.
    Not used: Payments, Live connection, Emails and texts, Push.
    With AI
    AI drafts the visit note from what was said, for the carer to check.
    What makes it hard
    Notes written with no signal that must never be lost, or saved twice.
    The store rule it meets
    The reviewer gets a way in

Learning

  • Your customers

    Courses, classes and progress

    Students and members

    Its first screens
    1. Courses
    2. A lesson
    3. Quiz
    4. Progress
    5. Membership.
    What it asks of the phone
    • Works offline, Needs it: Lessons saved for the train or the plane.
    • In-app purchases, Needs it: Courses bought through the store’s own checkout.
    • Notifications, Often: A nudge to keep going, when they choose.
    • Calendar, Often: Live classes in their own calendar.
    What runs behind it
    Runs here: Sign-in, API, Database, Payments, Files, Daily jobs.
    Built for yours: Push.
    Not used: Live connection, Emails and texts.
    With AI
    AI explains a lesson again, another way.
    What makes it hard
    Knowing which purchases go through the stores’ own checkout, and which don’t.
    The store rule it meets
    What the app sells decides who takes the payment

  • Your staff

    Attendance and updates, from the room

    Teachers, coaches and instructors

    Its first screens
    1. Today’s classes
    2. Attendance
    3. Scan in
    4. Post an update
    5. Messages.
    What it asks of the phone
    • Scanning codes, Needs it: A whole room checked in from their codes.
    • Notifications, Needs it: An update to every student at once.
    • Camera, Often: A photo of the board, posted to the class.
    • Works offline, Often: Attendance kept when the signal is weak.
    What runs behind it
    Runs here: Sign-in, API, Database, Files, Emails and texts.
    Built for yours: Push.
    Not used: Payments, Live connection, Daily jobs.
    With AI
    AI turns a photo of the board into notes for the class.
    What makes it hard
    Two teachers marking the same class without clashing, and each update reaching only the students it’s meant for.
    The store rule it meets
    The reviewer gets a way in

Money and loyalty

  • Your customers

    Points, payments and receipts

    Customers of a loyalty scheme, a club or a payment service

    Its first screens
    1. Wallet
    2. Pay
    3. Rewards
    4. Receipts
    5. Help.
    What it asks of the phone
    • Face or fingerprint, Needs it: Nothing opens or pays without it.
    • The phone’s wallet, Needs it: A card in the phone’s own wallet.
    • Scanning codes, Needs it: Paying or earning points with a code.
    • Notifications, Often: Every payment in or out, as it happens.
    What runs behind it
    Runs here: Sign-in, API, Database, Payments, Daily jobs, Emails and texts.
    Built for yours: Push.
    Not used: Files, Live connection.
    With AI
    AI answers questions about a payment.
    What makes it hard
    Every movement of money recorded once, and a sign-in a stolen phone can’t get past.
    The store rule it meets
    Sign in with Google on an iPhone? Then a private option too

  • Your staff

    Expenses and approvals on the go

    Teams who spend, and the people who approve it

    Its first screens
    1. To approve
    2. A request
    3. Scan a receipt
    4. Expenses
    5. Reports.
    What it asks of the phone
    • Camera, Needs it: A receipt photographed where it was paid.
    • Face or fingerprint, Needs it: An approval only the right person can give.
    • Notifications, Needs it: A request waiting for a yes.
    • Works offline, Often: Receipts captured with no signal.
    What runs behind it
    Runs here: Sign-in, API, Database, Files, Daily jobs.
    Built for yours: Push.
    Not used: Payments, Live connection, Emails and texts.
    With AI
    AI reads a crumpled receipt, and flags the ones a person should check.
    What makes it hard
    The same receipt never claimed twice, and a record of every approval that nobody can quietly change.
    The store rule it meets
    The reviewer gets a way in

Samples written for this page. Something else entirely? Bring yours to the call.

From prototype to both stores

An app your customers keep on their home screen.

Three stages, each ending in something you can hold and check before the next starts, and three gates on the way: your yes, your testers’ and the stores’.

The path, step by step

  1. 01A prototype on your phone
  2. 02Designed for both platformsGate: Your yes
  3. 03Built, with its server
  4. 04A beta, with your testersiOS: TestFlightAndroid: Testing trackGate: Your testers
  5. 05Each store’s reviewiOS: App ReviewAndroid: Play reviewGate: The stores’ review
  6. 06Published under your nameiOS: App StoreAndroid: Google Play
  7. 07Updates, the same way

Before review, every build goes to your testers:

  1. 01Stage

    Designed for iOS and Android

    We draw every screen that matters and link them into a prototype you tap through on your own phone. Then each screen is designed for both platforms: the same app, with each one’s own navigation, dialogs and gestures.

    You hold

    A prototype you’ve tapped through on your own phone, and the designs for both platforms.

    Now, in this browser:Tap through the sample above

  2. 02Stage

    Sign-in, payments and push built in

    The apps and the server behind them are built together, in the technology chosen at the prototype, and tried on real iPhones and Android phones as each part lands.

    You hold

    The app on your testers’ phones, working against its own server.

    On ours

    Sign-in with email or Google, Stripe payments and fiscal invoices, 8 account emails, booking texts in 14 languages, and an always-on service for live connections.

    Now, in this browser:Walk through ours on the free trial

  3. 03Stage

    Published to both app stores

    Apple and Google review each release against their rules, and it’s published from developer accounts in your company’s name. Every update goes the same way, and the crash reports both stores keep are watched.

    You hold

    Both apps in the stores under your name, and the code for the apps and the server.

    On ours

    Deleting an account from inside the product, which both stores require, already works here: after a fresh sign-in, the server removes the account and its data in thirteen steps with billing stopped first.

    Now, in this browser:The stores’ rules, below

The gates the stores keep

What Apple and Google ask of an app before it goes into their stores, quoted or summarised from their own pages, and what we do about each.

  • An account made in the app can be deleted in the app

    AppleApp Review Guidelines 5.1.1(v) (Apple’s site)

    “If your app supports account creation, you must also offer account deletion within the app.”

    In their words

    Google PlayGoogle Play: account deletion (Google’s site)

    Google Play asks the same, and a web page where people can ask for it too.

    Summarised

    On ours

    From Settings → Danger zone → Delete account, after a sign-in in the last 30 minutes. Billing stops first; an email confirms it.

    Start free

  • What the app sells decides who takes the payment

    AppleApp Review Guidelines 3.1.1 and 3.1.3(e) (Apple’s site)

    Features and content unlocked inside the app use Apple’s in-app purchase; physical goods and services used outside the app are paid another way, such as by card.

    Summarised

    Google PlayGoogle Play’s billing system (Google’s site)

    “Google Play’s billing system is only for digital items.”

    In their words

    For yours

    Settled at the prototype for each thing the app sells, before a screen is built the wrong way.

  • A privacy policy, in the store and in the app

    AppleApp Review Guidelines 5.1.1(i) (Apple’s site)

    “All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner.”

    In their words

    Google PlayGoogle Play: Data safety (Google’s site)

    Google Play asks for a privacy policy, and a form saying what the app collects and shares.

    Summarised

    For yours

    Linked in both store listings and from the app’s own settings.

  • An app has to do more than a website

    AppleApp Review Guidelines 4.2 (Apple’s site)

    “Your app should include features, content, and UI that elevate it beyond a repackaged website.”

    In their words

    For yours

    Built around what only a phone can do, from notifications to the camera, so it’s more than a repackaged website.

  • Sign in with Google on an iPhone? Then a private option too

    AppleApp Review Guidelines 4.8 (Apple’s site)

    An app that signs people in with a third-party or social account, such as Google’s, must also offer an equivalent option with the privacy features Apple lists.

    Summarised

    For yours

    Sign in with Apple beside Google’s, wherever the iOS app offers Google’s.

Whose name it’s in

What keeps the apps in the stores, and what another team would need to carry them on, is yours or agreed before the build starts.

Whose name it’s in
WhatWhoseHow
The Apple developer accountIn your name

Opened by your company, with us working in it as members of your team. Apple asks a company for its D-⁠U-⁠N-⁠S Number.

Apple’s enrolment page (Apple’s site)
The Google Play developer accountIn your name

Opened by your company, with us invited to it. Google Play asks an organisation for a D-⁠U-⁠N-⁠S number too.

Google Play’s page (Google’s site)
The name the stores showIn your name

“The legal entity name will appear as the seller for apps you distribute.”

Apple, on enrolment (Apple’s site)
The code for both apps and the serverHanded to you

With its tests and a guide to running it, at the end of the build.

What signs each new versionIn your name

Set up in your Apple and Google accounts, so another team could release the next one.

Hosting, database and messaging accountsAgreed first

Whose name they’re in is agreed before the build starts.

Behind the app

The half you don’t see, already running here

Almost every app talks to a server: to know who’s signing in, take payments, send messages and do the work nobody taps for. This platform, our own product for AI phone agents, runs eight of these nine parts, and every figure here is counted from its code. Yours gets its own, built with your app.

This platform’s own parts · drawn from its code

The app

  • Runs here: email · Google

    Sign-in and accounts

    For an app

    Who someone is, checked on the server whenever the app asks for anything: signing up, signing in, a forgotten password, a deleted account.

    On ours

    Email and password with a confirmation email, or a Google account; a reset link by email; sign-in attempts limited per network and per account; and an account deleted from settings after a fresh sign-in.

    Now, in this browser:Sign up on the free trial

  • Runs here: 80+ routes

    The API

    For an app

    Everything the app reads or changes goes through it, and it answers only what that person may see.

    On ours

    80+ API routes, from accounts and payments to live calls. Each request is checked on the server for who is asking, and systems calling in — the phone network, the payment provider, the daily job — prove who they are with a signature or a secret.

    On the call:Ask to see the route list

  • Runs here: 12 migrations

    The database

    For an app

    What the app keeps — accounts, bookings, orders — with each customer’s records walled off from everyone else’s.

    On ours

    Postgres on Supabase in eu-⁠west-⁠1 (Ireland). Row-level security walls off each business’s rows, and every change to its shape is one of 12 migrations kept in the repository.

    On the call:Ask us to open the migrations

  • Runs here: 7 Stripe events

    Payments

    For an app

    Takes the money and tells the server it arrived, so nothing is confirmed on the phone’s word.

    On ours

    Stripe Checkout and a customer portal, a signed webhook that keeps plans in step on seven kinds of event, and SmartBill fiscal invoices, each issued only after a check for one on record. Card numbers never reach our servers.

    Now, in this browser:Choose a plan on the free trial

    The card form opens on Stripe’s own address.

  • Runs here: signed uploads

    Photos and files

    For an app

    Photos, scans and documents people add, sent straight to storage and kept only while something uses them.

    On ours

    Uploads go straight to storage through a one-time signed link, never through the app’s server; storage itself checks each file’s size and type, and the daily job removes day-old uploads that nothing uses.

    Now, in this browser:Add a document on the free trial

  • Runs here: always on

    A live connection

    For an app

    For whatever changes while you watch: a chat, a driver on a map, times filling up, a call.

    On ours

    An always-on service on Node.js 22 holds each live call open; a browser joins with a signed token that expires in 60 seconds, and the dashboard updates as calls change. On an iPhone, the test call picks its sound back up after a phone call, Siri or a locked screen interrupts it, or asks for a tap.

    Now, in this browser:Make a test call on the free trial

  • Runs here: 07:00 UTC

    Jobs that run themselves

    For an app

    The work nobody taps for: reminders, renewals, clean-ups and reports.

    On ours

    One job every morning at 07:00 UTC, eight steps that each run on their own. Its reminder step claims each booking before texting it, so two runs can’t send one twice, and a text that fails frees it to try again.

    On the call:Ask to see a morning’s run

  • Runs here: email · text

    Emails and texts

    For an app

    What the app sends when it isn’t open: receipts, confirmations, reminders and warnings.

    On ours

    Eight account emails, from a welcome to a receipt, and five kinds of booking text in 14 languages, the texts sent through Twilio. Turn notifications off in the sample above, and the text it shows is this platform’s own reminder, word for word.

    On the call:Ask to see a reminder go out

  • Built for yours

    Push notifications

    For an app

    A message on the lock screen, even with the app closed, once the person has said yes.

    Not on ours: this platform sends emails and texts, not push notifications. Yours sends push too, through Apple’s and Google’s own push services.

    In your build:Built with your app

Where each part lives in the code

In the code, for your developers

Sign-in

  • lib/auth/actions.ts
  • lib/auth/throttle.ts
  • app/auth/callback/route.ts
  • app/api/account/route.ts

API

  • app/api
  • proxy.ts
  • lib/api/auth.ts

Database

  • supabase/migrations

Payments

  • app/api/billing/checkout/route.ts
  • app/api/billing/portal/route.ts
  • app/api/billing/webhook/route.ts
  • lib/smartbill/emit.ts

Files

  • app/api/agent/knowledge/upload-url/route.ts
  • app/api/voices/_lib/storage.ts
  • app/api/cron/storage-cleanup.ts

Live connection

  • services/voice-gateway/src/server.ts
  • services/voice-gateway/fly.toml
  • app/api/voice/test-session/route.ts
  • lib/audio/resume.ts
  • hooks/useCallsChanged.ts

Daily jobs

  • vercel.json
  • app/api/cron/daily/route.ts
  • lib/scheduling/reminders.ts

Emails and texts

  • lib/email/templates.ts
  • lib/sms/templates.ts
  • lib/twilio/sms.ts
  • lib/notifications/index.ts

Push

Built for yours

Drawn by the team that built it, from its code. It’s a drawing, not a live feed.

Who builds it

The people who build it hold 20+ Claude accreditations

The team that built this platform, from its sign-in to its live calls, and builds apps of any kind, for any business.

Personal accreditations

20+

Claude accreditations, from Anthropic

Each was earned by one of the people who’d design and build your app, for building with Claude, Anthropic’s AI. We build with it too, this platform included: where your app should read a photo, answer a question or sort what people send in, the people building it already know how.

They’re personal, not a certification of our company.

On the call:Ask to see the accreditations

Startup grants, awarded to our company

  • Cartesia
  • ElevenLabs

Their technology runs inside this platform: where your app should speak or listen, we already build on it.

What each one is, and how to see it

A grant isn’t an endorsement of this page, or of any build we quote.

On the call:Ask to see the grants

Before it starts

What we’ll ask, what you’ll get, and what we say up front

There’s no price or date on this page: both go in the quote, because both depend on what the app has to do. Here’s what moves them.

What sets the price and the date

  • Which kinds of people use it, and what each may see or do
  • Native for each platform, one codebase for both, or code you already have
  • What it asks of the phone: camera, location, working offline, payments
  • Anything live: chat, tracking, calls
  • The systems it connects to, and whether its server exists yet
  • Where your users are, and the rules that come with that

What we’ll need from you

  • A conversation about who uses it, what they do in it, and what they must never be able to do
  • Whatever exists already: sketches, a website, a spreadsheet, an old app
  • One person who can say yes or no at each prototype review
  • Developer accounts with Apple and Google in your company’s name — we’ll walk you through opening them
  • Testers from your side for each beta, and your yes before anything goes to the stores

What you get

  • Designed for iOS and Android
  • Sign-in, payments and push built in
  • Published to both app stores
  • The code for the apps and the server, with tests and a guide to running it

Said up front

  • A prototype isn’t the app: you tap through it on your phone, but it stores nothing and charges no one.
  • Apple and Google review every release against their own rules. We build to them; the decision is theirs.
  • The stores have fees of their own; the quote says which apply to yours.
  • Hosting, messages and the other services it runs on bill for what they supply, on top of the build; the quote lists them.
  • If a website that works well on phones would do the job, we’ll say so on the call.
  • Who makes changes after launch — your team, us, or both — is agreed when the build is quoted.

If it’s a whole platform, an automation or a phone agent you need, the same team builds those too.

How a SaaS platform is builtHow a custom automation is builtHow a custom phone agent is built

Check it yourself

The claims that matter most, and where to check them

Some you can check now, in this browser.

Some we show you on the call.

The rest you get in your build.

  • Now, in this browser:

    The sign-in, payments and account emails drawn with the sample run on the platform you can try.

    Start the free trial: sign up, confirm your email and choose a plan.

    Start free

  • Now, in this browser:

    Card numbers go to Stripe and never reach our servers.

    Choose a plan in the trial: the card form opens on Stripe’s own address.

  • Now, in this browser:

    An account can be deleted from inside the product, as both stores ask of an app.

    On the trial: Settings → Danger zone → Delete account. It asks for a sign-in within the last 30 minutes first.

    Start free

  • Now, in this browser:

    Every store rule under ‘The gates the stores keep’ links to the store’s own page.

    Each card names its source and marks a quote ‘In their words’ and a summary ‘Summarised’.

    The gates

  • Now, in this browser:

    We’re an EU company, registered in Romania.

    The legal name, the CUI and the address are at the foot of this page.

  • On the call:

    Our team holds 20+ Claude accreditations from Anthropic.

    Ask to see them.

  • On the call:

    Cartesia and ElevenLabs each awarded our company a startup grant.

    Ask to see them.

  • On the call:

    Every figure about this platform is counted from its code.

    By a test that fails if a figure stops being true. Ask us to run it.

  • On the call:

    A reminder goes out once, even if the job runs twice.

    Ask us to open the reminder step: each booking is claimed before its text goes out, and freed again if the text fails.

  • In your build:

    You tap through the prototype on your own phone first.

    It’s what stage 01 delivers; the sample above shows the idea.

    The sample

  • In your build:

    Both apps are published from developer accounts in your company’s name.

    Opened in your name before the first beta; we work in them as your team.

  • In your build:

    The code is handed over.

    Both apps and the server, with their tests and a guide to running them, are yours at the end of the build.

How you check yours

Yours starts with a call. Then come the three stages above, each one yours to check as it lands: a prototype on your phone, the app working in your testers’ hands, and both store listings under your name, with the code handed over.

Call us about a build

Questions

What people ask before a build

Call us about a build

+40 774 566 367

Your name says ‘Voice’. Do you only build voice apps?

No. We build whatever app your business needs — for bookings, shopping, delivery, learning, health, money or your own team’s work — with AI in it where it helps, or none at all. Neuro Tech Voice is also the name of our own product, a platform for AI phone agents; its server side is on this page because it’s ours to open up, not because voice is all we build.

How do we know you can build our app?

Check what this page shows. The server side an app needs already runs on this platform, which you can try for free, and the people who’d build yours hold the accreditations above. Then check yours as it lands: before any code is written, you’ll have tapped through a prototype of your own app on your phone, and every build reaches your testers before either store’s review.

Should it be an app at all?

Not always. If people use it once in a while, a website that works well on phones may do, and cost less; we’ll say so on the call. An app earns its place when people come back to it, or when it needs the phone itself: notifications, the camera, location, or working with no signal. Apple’s own rules ask the same of an app.

Apple’s rule on it

Which technology do you build in?

Whichever the product needs, or you prefer. Many apps are written once, in React Native with Expo or in Flutter, and built for both stores; apps that lean hard on the phone — the camera all day, audio, devices they connect to, widgets — are written natively, in Swift and SwiftUI for iOS and in Kotlin and Jetpack Compose for Android. We choose it with you at the prototype, and say why.

Will Apple and Google approve it?

We build to both stores’ published rules from the first screen — deleting an account in the app, a privacy policy, a way in for the reviewer, the right checkout for what it sells — and every build goes to your testers before review. The decision is the stores’: if a reviewer asks for a change, we make it and send it back.

Who owns the app, the code and the store accounts?

You do. The Apple and Google developer accounts are opened in your company’s name, so it’s the name the stores show, and we work in them as members of your team. At handover the code for the apps and the server is yours, with its tests and a guide to running it. Whose name the hosting accounts are in is agreed before the build starts.

Do we need a server, and who runs it?

Almost every app does, for accounts, payments, messages and anything people share. We build it with the app and hand over its code with the app’s; if you already run one, the app can talk to yours. Who runs it after launch — your team, us, or both — is agreed when the build is quoted. The parts on this page are what this platform runs for itself: yours gets its own.

Can it send push notifications?

Yes, through Apple’s and Google’s own push services, once each person has said yes. This platform doesn’t send push: it sends emails and texts, such as its booking reminders. So push is built for yours, with a text or an email for people who turn notifications off.

What does it cost, and how long does it take?

It’s quoted after the call, because both depend on what the app must do: how many kinds of user, which technology, what it asks of the phone, and what it connects to. We won’t put a number here that we’d have to walk back.

We already have an app, or a website. Can you take it on?

Tell us about it on the call, then give us read access to the code. We’ll tell you plainly whether we’d carry on from it or start again, and why.

Where would our data live?

Where your app needs it to, chosen with you before anything is built. This platform keeps its database and file storage in the EU, in eu-⁠west-⁠1 (Ireland), while its call recordings stay with the provider that captured them, and ElevenLabs or Cartesia can keep their own copy of a call they handled. Twilio and ElevenLabs keep theirs in the US, and we haven’t confirmed Cartesia’s country. Some of the other services it uses are outside the European Economic Area too, and the privacy policy says how those transfers are safeguarded. The company that builds it is in the EU as well, registered in Romania.

Read the privacy policy

Start

Bring the app idea, and who it’s for

A build starts with a phone call, not a form. Tell us who’ll use the app, what they do in it and what it connects to. We’ll tell you what we’d build first, in which technology, and what it would take.

Call us about a buildTry the platform we built

+40 774 566 367 · Quoted after the call, never on the page

About this page

The sample app
Made for this page: a booking app for no business in particular. It stores nothing, charges no one and sends nothing; its buttons only change the picture. Its two looks follow each platform’s own conventions; they aren’t Apple’s or Google’s screens.
The parts behind it
Neuro Tech Voice’s own, our product for AI phone agents, drawn from its code. It’s a drawing, not a live feed, shown because it’s ours to open up, not because voice is all we build.
The reminder text
Word for word the reminder this platform texts for its customers’ bookings, taken from its code when the page is built; the time is left out.
The figures
Counted from its repository by the site’s own tests. A figure with a plus is a floor: the real count is at least that.
The samples
The kinds of app under ‘Your kind of app’, with their screens and what they ask of the phone, were written for this page, for no business in particular.
The store rules
Quoted or summarised from Apple’s and Google’s own pages, each linked where it’s used. The stores change them; their pages are the word that counts.
Accreditations and grants
The accreditations are held by people on the team; the grants were awarded to the company by Cartesia and ElevenLabs. Both are shown on the call, on request.
What isn’t here
No client names, logos, testimonials, prices, dates, download counts or store ratings appear on this page.
Anthropic and Claude
Anthropic and Claude are trademarks of Anthropic, PBC. Naming them is not an endorsement by Anthropic of this page or of any build.
Apple
Apple, iPhone, App Store, App Store Connect, TestFlight, Siri, Swift, SwiftUI and Sign in with Apple are trademarks of Apple Inc., registered in the U.S. and other countries and regions. IOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used under license. Neuro Tech Voice is not endorsed by Apple.
Google
Google, Android, Google Play, Jetpack Compose and Flutter are trademarks of Google LLC. Neuro Tech Voice works with them and is not endorsed by Google.
Other names on this page
Cartesia, ElevenLabs, Stripe, SmartBill, Supabase, PostgreSQL, Twilio, Node.js, React Native, Expo, Kotlin and D-⁠U-⁠N-⁠S are trademarks of their respective owners. We build on them, or name them where the stores do; none of them endorses this page or any build we quote.