skillschedule.com
Coaching and youth-sports SaaS
A coaching platform on web and mobile, with billing that survives refunds.
v1.0.4 SkillSchedule’s iOS and Android app, built on Expo alongside the web portals
ClientSkillSchedule
Read the case →Service · Mobile app development
Mobile app development that reaches both stores.
We build iOS and Android apps, finish half-built ones, and take Lovable, Bolt, FlutterFlow or Expo prototypes through App Store and Play Store review. The app shares one API with the web portals, so sign-in, billing and refunds behave the same everywhere.
30 minutes. A written gap map. No pitch unless you ask for one.
v1.0.4
SkillSchedule’s iOS and Android app, built on Expo alongside the web portals
receipt
SOURCE · SkillSchedule mobile repository (app version and EAS build configuration)
METHOD · Version string from the app’s production build configuration.
VERIFIED · 2026-09
CLASS · repository
✓ every number on this site opens its receipt
CLAIM · app-store-live
How we count✓ EAS builds
iOS and Android through one managed pipeline
iOS and Android through one managed pipeline
Sign-in · push · payments
Apple and Google sign-in, Stripe, crash reporting
Apple and Google sign-in, Stripe, crash reporting
01 · What goes wrong
The app runs on your phone. Then it has to run on everyone else’s.
The problems founders bring us with a mobile app, in their words. One is enough to start asking questions.
- Demo-grade
The prototype works on my device and nowhere else.
A FlutterFlow, Bubble or Expo demo runs on the founder’s phone with a pasted API key. Real users bring sign-in, dropped connections, old OS versions and a payment flow Apple has rules about.
- Rejected
Store review rejected the build, and nobody knows why.
Missing privacy labels, a sign-in flow that breaks Apple’s rules, a test account the reviewer couldn’t use. Each round trip costs days, and the fix is often in the backend, not the app.
- Two truths
The app and the web portal disagree.
Two codebases talk to two backends, or to one backend with two sets of rules. A refund works on the web and fails in the app, and support hears about it from the customer.
- Abandoned
The developer left mid-stream.
Half the screens are wired, the build runs on a laptop, and the signing certificates are in someone’s inbox. Finishing the app means recovering the project before writing a line.
- Unmeasured
It launched, and nobody knows what users do in it.
No tracking plan, no crash reporting, and conversions counted by a browser that is never open on a phone. The first month’s data can’t say where people give up.
02 · What we build
The app, the backend behind it, and the pipeline that gets it into the stores.
Three ways in, one set of foundations: from scratch, from a half-built app, or from a prototype that proved the idea.
01From scratch
An app on real foundations
Expo and React Native for iOS and Android from one codebase, or Flutter where the project calls for it, over an API designed to serve the app, the web and the admin together.
02Finishing
Your half-built app, finished
We recover the project, the signing keys and the build, keep the product decisions you validated and rebuild only what production demands. The written plan says which parts, before a line changes.
Launch Engineering03Prototype
Lovable, Bolt, FlutterFlow or Bubble, taken to the stores
The prototype is the spec. Sign-in you’d trust with a stranger’s data, payments through Stripe’s native sheet and a backend that isn’t a pasted API key, then the store builds.
04Stores
App Store and Play Store review, handled
iOS and Android builds through managed pipelines, with signing, privacy labels, a reviewer test account and the store listing in the plan. Submission is part of launching, not a separate line item.
05Backend
One API behind the app and the web
Apple and Google sign-in, roles, push notifications, billing and refunds that behave the same in the app and the portals, because they run through the same server code.
Product Engineering06Measurement
Crash reporting and a tracking plan from day one
Crash reporting on every build, a written tracking plan, and conversions recorded by the API so they count when no browser is open. The first month’s report tells you what to fix next.
03 · Proof you can check
Apps built for both stores, apps we run, and the pipelines behind them.
A client’s app built on Expo alongside its web portals, and the apps we run ourselves, labeled as ours. A client we may not name yet is described, not named. Every figure opens its receipt: where it came from, how it was counted, and when we last checked.
6
of our repos started as scaffolds in Bolt.new, an AI app builder, before our engineers took over
Four web front-ends and two product prototypes. We start where many founders start.
receipt
SOURCE · Synaptech portfolio repositories
METHOD · .bolt project directories found during the September 2026 portfolio audit, counted conservatively: four web front-ends and two product prototypes. More of our repositories carry .bolt folders and are not counted here.
VERIFIED · 2026-09
CLASS · repository
✓ every number on this site opens its receipt
CLAIM · bolt-scaffolds
How we countThe work behind the numbers
Also on the books
Automotive retail · a 12-rooftop auto group
Scan a license, skip the form
A Flutter customer app for a 12-rooftop auto group: on-device license and document scanning prefills accounts and vehicles, alongside two-factor sign-in, insurance-card capture, service booking and a dealership locator.
Client
Consumer audio · House of Marley
One app for a whole line of Bluetooth audio
A unified app that controls House of Marley’s Bluetooth speakers and headphones across different chipsets, with saved equalizer presets, noise cancellation and ambient-sound control in one place.
Client
Water filtration (IoT) · Aquavis
Water-filter health, monitored automatically
An IoT system for a water-filtration company: a sensor PCB tracks filter health, the cloud processes the readings, and a mobile app alerts households when a filter needs attention.
Client
Surrogacy matching marketplace · SurroGet
A regulated matching marketplace with honest scores
A surrogacy marketplace with server-enforced verification gates, staff screening queues, an Android build on Google Play’s internal track, and a Meta Pixel and Calendly acquisition funnel. Its compatibility engine replaced a vendor’s random-number “scores” and returns nothing rather than a fake number.
Our own product
- ClientSkillScheduleAn Expo app with Apple and Google sign-in, push notifications, the Stripe payment sheet and crash reporting through Sentry and Bugfender, with iOS and Android builds produced through EAS.
- Venture we operateTriaPetAn Expo app for iOS and Android on the same API as the pet-owner portal, the clinic dashboard and the admin, with a written tracking plan and conversions recorded by the server so they count when no browser is open.
- Store submission is part of launching: managed build pipelines, internal test tracks first, then App Store and Play Store review.
04 · How it starts
Backend and sign-in first. Then money and push. Then the stores.
The same order every time, because each step protects the next. You see the plan before we start and the build on your own phone before it goes to review.
Every line of code we ship runs on one rule: AI drafts, senior engineers decide. How we build →
Step 1: The free Production Gap Review
Bring the app, the prototype share link, or just the idea. We walk it together, then hand you a written gap map across the backend, sign-in, payments, push, the build pipeline, store readiness and tracking.
Out a written gap map, yours to keep
Step 2: A fixed, scoped plan
If there is a fit, you get a fixed price and a written plan: what we keep, what we rebuild, and why. If there isn’t a fit, we say so.
Out fixed price + written plan
Step 3: Backend and sign-in
The API, roles, sessions and Apple and Google sign-in go in before any screen gets its polish, so the app and the web portal share one set of rules from the first build.
Out one API, roles under test
Step 4: Money and push
Stripe’s payment sheet, refunds, receipts that match the charge, and push notifications, with tests on every path that moves money.
Out money paths under test
Step 5: Builds and store review
Managed build pipelines for iOS and Android, crash reporting on every build, internal test tracks first, then App Store and Play Store submission with the listing, privacy labels and a reviewer account ready.
Out submitted to both stores, monitored
Step 6: After launch
A tracking plan that counts what users do, a first report that says where they give up, and the Growth Engine or Product Engineering when there is something to fill or to outgrow.
Out a next step, not a hand-off
05 · Straight answers
Questions founders ask before they build an app.
Expo, React Native or Flutter?
Expo and React Native are our default for a new app: one codebase for iOS and Android, managed build pipelines, and the same TypeScript the backend speaks. We have shipped Flutter where the project called for it, including a dealer group’s customer app with on-device document scanning. The gap map says which fits your app, and why.
What we won’t do is rewrite a working Flutter app into React Native to suit ourselves.
Can you finish an app another developer started?
Yes. We start by recovering the project: the repo, the signing certificates, the store accounts and the build. Then the review maps what works, what is wired to nothing, and what production demands. The plan keeps what you validated and rebuilds only the rest.
I built a prototype in Lovable, Bolt, FlutterFlow or Bubble. Can it go to the stores?
Often part of it can, and the rest becomes the spec. Several of our own repos started as scaffolds in an AI app builder, so we are not snobbish about where a product begins. The line these tools don’t cross is sign-in you’d trust with a stranger’s data, real payments, push notifications and a build Apple and Google will accept.
The review shows exactly where that line is for your app.
Do you handle App Store and Play Store submission?
Yes. It is part of launching, not a separate line item. iOS and Android builds go out through managed pipelines to internal test tracks first, then to review, with the listing, privacy labels and a reviewer test account prepared. When a build is rejected, we read the reason and fix it, which is often in the backend rather than the app.
Does the app need its own backend?
No, and it usually shouldn’t have one. The app shares one API with the web portals and the admin, so sign-in, roles, billing and refunds behave the same everywhere and every fix ships once. That is how we built a coaching platform’s app alongside its parent, coach and admin portals.
What does store review usually reject?
Missing privacy labels, a sign-in flow that breaks Apple’s rules, a reviewer test account that does not work, and purchases that belong in the store’s own payment system but go around it. We prepare each of those before submission. When a build still comes back, we read the reason and fix it, which is often in the backend rather than the app.
06 · The front door
Find out what’s between your app and the stores.
Bring the app, the prototype or just the idea. Leave with a written gap map across the backend, sign-in, payments, push, the build pipeline and store readiness, before you spend a dollar. If we’re not the right team to close the gaps, the map is still yours.
30 minutes. A written gap map. No pitch unless you ask for one.
- Product live but empty?
Get a free Growth Engine Audit - Not ready to talk?
Get the Production Gap Checklist
info@synaptech.io +1 (925) 255-9507 Pleasanton, CA