How to Build a Machine Learning App in 2026: Steps, Tech Stack, and Costs

Every phone in your users’ pockets runs models all day. Keyboard prediction, photo search, noise suppression on a call, the order of a feed: machine learning turned into infrastructure and stopped announcing itself.

What changed for the people building is the first decision. In 2022, machine learning app development meant picking a framework and starting to train. In 2026 you start by asking whether anything needs training at all, because a hosted foundation model probably already does the job for the price of an API call.

Eight steps take you from problem definition through MLOps. Around them: the stack teams actually use this year, where to run the model, what it costs to build and to run, and what regulators want once the model touches a clinical decision.

Should I train my own ML model or just use an LLM API?

Use a hosted model API first, and train your own only when latency has to stay under about 100 ms, the data can’t leave your infrastructure, or per-call pricing breaks at your volume. Budget $20,000 to $50,000 for the ML work on top of a normal app build, plus an inference bill that arrives every month and grows with usage.

Key Takeaways:

• Three paths, in ascending order of cost and time: call a hosted model, fine-tune a foundation model, or train your own. Most 2026 products should start at the first and move only when something forces them.
• The ML work runs $20,000 to $50,000 on top of the base app, once. The machine learning app development cost that blindsides teams is inference, billed monthly for as long as the feature is live.
• On-device machine learning is a first-class option now: Core ML, LiteRT and Apple’s Foundation Models framework run models on the phone itself, which kills the round trip, the inference bill, and the data-residency conversation.
• Classical ML still wins on tabular prediction, ranking, anomaly detection, and anything that has to run at frame rate. A language model is the wrong tool for a measurement problem.

Table of Contents

1. Custom ML or an LLM API: which does your app need?
   • When classical ML still wins
2. How to build a machine learning app in 8 steps
   • Step 1: Define the problem
   • Step 2: Assemble the right team
   • Step 3: Define your app’s architecture
   • Step 4: Pick the tech stack
   • Step 5: Get the data ready
   • Step 6: Build, train, and validate the models
   • Step 7: Deploy the models into your app
   • Step 8: Maintain ML operations
3. On-device machine learning in 2026
4. How much does it cost to build a machine learning app?
5. Compliance and risk: when your model becomes a regulated device
6. Real ML apps we’ve built
7. How Topflight approaches machine learning app development

The eight steps are the same whether you create a machine learning app around a model you trained or one you rent. What changes inside them is the answer to step 1.

Custom ML or an LLM API: which does your app need?

This is the question every 2026 project opens with. There are three ways to put intelligence into an app: call somebody else’s model, adapt somebody else’s model, or train your own. They differ by roughly two orders of magnitude in cost, and about the same in time to a working version.

Each step right buys you control and costs you months.

Start on the left and move right only when something forces you. A hosted model with decent retrieval and a real eval suite carries more products than teams expect. The forcing functions are genuine, though: a latency budget under about 100 ms, data that cannot leave your infrastructure, a task with no language in it at all, or per-call economics that stop working at your volume.

LLM integration has its own shape of work, and most of it is retrieval: chunk your documents, embed them, keep the vectors in a vector database, and hand the model the right passages at query time. That pattern is retrieval-augmented generation. It’s how a general model answers questions about your data without ever being trained on it, and it’s usually the cheapest way to make a hosted model feel domain-specific.

If your product is mostly a language interface over documents or conversations, you’re on the LLM-first path and our AI app development guide covers that build end to end. This article stays with machine learning proper: models you train or convert, running against your own data.

When classical ML still wins

A gradient-boosted tree will beat a language model at a tabular task and answer in a millisecond. The cases where a trained model is still the right call are specific, and they’re common:

• prediction over structured data, like churn, risk scoring, demand or price
• ranking and recommendation, where you order thousands of items per request
• anomaly detection over streams, where the pattern lives in the numbers
• vision and pose work that has to run at frame rate on a phone
• anything whose inference volume makes per-call pricing absurd

Allheartz is the shape of it. Pulling joint angles out of a patient’s exam video is a measurement problem, and a pose model does it at frame rate for nothing. Ask a hosted language model for the same numbers and you pay per frame for a worse answer.

How to build a machine learning app in 8 steps

Design, prototyping, coding, QA and release work the same as they do on any other app, so these eight steps cover what changes once there’s a model inside one.

Step 1: Define the problem

Obvious, and still where projects go wrong. Two questions before anything else:

• What does the user get here that they don’t get today?
• Could a foundation model already do this through an API, with nothing trained?

That second question is new since 2022 and it kills a lot of ML projects, in a good way. Classification, extraction, summarizing, rewriting, answering questions over your own documents: a hosted model does all of that on day one, and the honest comparison is a week of API work against three months of training and labeling. Run the comparison before you rent a GPU.

The older question survives too. A chatbot with a hardcoded dialog tree needs no model. Rules beat models whenever the rules are knowable, and ML earns its place when the pattern is real and too messy to write down as rules.

Apple’s and Google’s own guidance add a few more worth answering while the idea is still cheap to change: what happens when the model is wrong, what a good outcome looks like from the user’s side, whether you have enough data to train something durable, whether users can correct it, and whether the model is supposed to improve over time.

Related: How to Build a Chatbot

Step 2: Assemble the right team

Beyond the app developers, backend engineers, designers and QA any build needs, ML app development adds people. The titles separated over the last two years, so know which one you’re hiring.

• An ML engineer trains and serves models, owns the pipeline and the drift monitoring, and is who you need if you are training anything at all.
• An AI engineer builds on models somebody else trained: retrieval, evals, prompting, tool calls, cost control. Most 2026 products want this role first.
• A data scientist frames the problem, works the data and decides what “good” means, which matters most before there is a model to train.
• A data engineer builds the training data pipeline, and gets skipped until the first time the data arrives broken.

If you’re calling a hosted model, a strong backend engineer with AI-engineering experience can carry the whole ML side. If you’re training, you need the ML engineer and someone owning the data behind them.

Related: How to hire app developers to build a winning app

Related: Mobile Quality Assurance Guide: Steps, Tools, Best Practices

Step 3: Define your app’s architecture

Machine learning in mobile apps can live on a server you call, on the device itself, or split across both. That choice sets your latency, your privacy story and a large share of your running cost, so make it before anyone writes code.

The hybrid column is where most products land, and it is the one that costs twice.

Cloud is the easier build. The app makes a call, gets an answer back, and every bit of ML complexity lives on a server you control. Pick it when the model retrains continuously, when it’s too large to ship, when several clients will share it, or when the answer has to be combined with data pulled from other systems. We kept Allheartz server-side on purpose, so the research team could change the pose model without an app release behind every change.

On-device is the better experience wherever it fits. No round trip, so no waiting. Nothing leaves the phone, so the privacy conversation gets short. No inference bill, and it works on a plane. Phones have real hardware for this now, the Neural Engine on Apple silicon and a neural processing unit (NPU) in most Android flagships, and a quantized vision or ranking model is small enough to ship inside a normal download.

Machine learning rides on top of a normal app build, so the team doing your custom mobile app development has to handle both halves.

Hybrid is where most products end up, and it costs the most because you maintain two paths for one feature. A translation app that downloads a single language pair for offline use and calls a server for every other language is the shape of it.

Step 4: Pick the tech stack

Python still wins and it’s not close. Every serious ML library targets it first, and the ones that matter now are PyTorch for training, Hugging Face Transformers for anything built on a pretrained model, and scikit-learn for the classical work a neural network would be overkill for. JAX is worth knowing for research-grade numerics. Go, C++ and Rust turn up on the serving side where latency is the constraint. The rest of the stack you pick the way you would for any app.

You can also skip most of it. Hosted models from OpenAI, Anthropic and Google arrive over an HTTPS call, and the managed platforms from AWS, Google and Microsoft will train and serve for you if you would rather not run GPUs yourself. On the device side, Core ML, LiteRT and ML Kit cover mobile, and LiteRT reaches microcontrollers as well, which is how the same approach gets into IoT hardware.

Two things about that table. Names in this category rot fast, so anything you inherit from an older guide is worth a check: MXNet went to the Apache Attic in 2023, Caffe2 was absorbed into PyTorch, Google Cloud AI Platform became Vertex AI and then the Gemini Enterprise Agent Platform in 2026, and TensorFlow Lite became LiteRT in 2024. And you won’t need most of the rows. A first ML feature usually runs on Python, one framework, one hosted model or one converted file, and whatever your app already uses.

Step 5: Get the data ready

Data availability is why the first honest question in an ML project is whether you have enough of it. Collecting it is the easy half. Before anything trains, you have to clean, normalize and segment it: make the values numeric, strip out noise and errors, collapse duplicates, and drop the input variables that carry no signal. Garbage in, garbage out is an old line and still the whole of it.

Then split it. The rule of thumb is still 80/20, with 80% going into the training set and 20% held back to test what comes out, and the training data labeled so the algorithm has a correct answer to learn from. Labeling is the part founders underestimate, and it’s where most of a fine-tuning budget actually goes.

Two things changed since 2022. Synthetic data is now a normal way to cover cases your real data is thin on, generated from a model and mixed in carefully, because a model trained mostly on its own output degrades. And labeling tooling got much better: Label Studio and its peers let a model pre-label and a human correct, which beats labeling from zero by a wide margin.

Step 6: Build, train, and validate the models

Three ways in, and they cost very different amounts.

• Fine-tune a foundation model on your own labeled examples. Cheapest route to a model that behaves the way your domain needs, and usually the right answer for classification, extraction and domain-specific language work.
• Adapt a published model through transfer learning, still the standard move for vision and audio.
• Train from scratch, for tasks where nothing published fits your data. This is the path that genuinely needs a data science team.

Drift is the failure that throws no error, which is why the loop closes rather than ends.

Most of this step is comparison. Your data scientists train several candidates, measure them against the held-out set, then take the one that clearly wins or blend the best few. Classification predicts which class something belongs to. Regression predicts a continuous value. A surprising share of product features turn out to be one of those two wearing a different hat.

A few things that save pain later: convert early if the target runtime needs a different format, because an architecture that won’t convert is better discovered now; validate only on data the model has never seen; and write the evals before you need them, as a fixed set of inputs with known-good outputs you can run on every version. For LLM-backed features that means graded examples, because the output is prose and an equality check tells you nothing.

What you want at the end is a model whose failures you can name, plus an eval that catches a regression on any of them. That’s what makes it shippable.

Step 7: Deploy the models into your app

Model deployment is the small part, at least from the app side. Call an API, or bundle a converted model and load it. The work sits in the conversion and in everything that happens after.

Conversion is where models go wrong quietly. A PyTorch model reaches an iPhone through Core ML, or through ONNX and ONNX Runtime, or through ExecuTorch, which PyTorch shipped as a stable on-device runtime in October 2025. Android takes LiteRT. Every conversion can shift numerics, so the training numbers stop applying. Re-run your evals on the converted artifact. Quantize on purpose: an 8-bit model that fits the download budget beats a 32-bit one that pushes the install past what users will sit through.

Server-side, decide early between a managed endpoint and your own GPU. Serverless GPU inference bills per second and idles at zero, which suits bursty traffic and early products; a dedicated instance gets cheaper once utilization is steady. Either way, put an ML pipeline behind it so data extraction, preprocessing, training and deployment run as one automated path.

Step 8: Maintain ML operations

Shipping the model starts its operating life. The app needs the usual upkeep for new OS releases and bugs, and the model needs its own retraining and versioning, plus some way of noticing when it has quietly stopped working.

Model drift is the failure that never makes it onto a roadmap. The input distribution shifts as the world moves, and accuracy decays without throwing a single error. Watch the inputs as well as the outputs, and keep an eval suite you run against every model version before it reaches a user. For anything backed by an LLM the eval suite is the regression test, because there’s no unit test for a generated answer.

Tooling worth knowing in 2026:

• MLflow for experiment tracking, the model registry and deployment
• Weights & Biases for training runs and evaluation
• Gemini Enterprise Agent Platform pipelines, the former Vertex AI, for managed training and serving on Google Cloud
• Kubeflow when the pipeline has to run inside your own Kubernetes

The 2022 version of this list recommended Algorithmia, which folded into DataRobot after the 2021 acquisition and no longer answers on its own domain. That’s the pace this category moves at, and the reason tool names on a page like this need a review date.

On-device machine learning in 2026

Machine learning in mobile apps runs locally now. Apple and Google each ship a runtime, a task library and a system language model on the device itself, and none of it costs you an API call.

The system model is free on both platforms, which is what changed since 2022.

On iOS, Core ML runs any model you convert and puts it on the Neural Engine without being asked. Apple’s Foundation Models framework, which arrived with iOS 26 in September 2025, goes further and hands your app the same roughly 3-billion-parameter model behind Apple Intelligence: on-device and offline, with no inference cost. At WWDC26 Apple widened it past its own model: Core AI runs local models you supply on the Neural Engine, MLX opens the Hugging Face MLX community, and Private Cloud Compute and outside providers like Claude and Gemini sit behind the same Swift API for work that genuinely needs a server.

On Android, LiteRT is the runtime. It’s what you knew as TensorFlow Lite, renamed in September 2024, and the .tflite format didn’t change with it. ML Kit and MediaPipe sit above it for the common vision and audio tasks. Gemini Nano reaches your app through the ML Kit GenAI APIs, so it never ships inside your APK and your download stays small. If you want one model file for both platforms, ONNX Runtime converts once and runs through the Core ML execution provider on iOS and NNAPI or XNNPACK on Android.

What edge AI handles well on a phone today:

• vision and pose models, quantized
• ranking and recommendation over local data
• speech and short-text classification
• small language models that summarize or rewrite what’s already on screen

On-device runs out of road at recall. A 3B model has thin world knowledge and a short context window, so anything that has to remember facts, read a long document or reason across a corpus goes back to a server. Most real products end up hybrid. Classical models are the easier win on the device side, small enough to ship and fast enough to feel instant.

How much does it cost to build a machine learning app?

$20,000 to $50,000 and up for the machine learning work, on top of whatever the app itself costs. That’s the range our app development costs guide puts on ML as a feature, and it holds in 2026 as long as you’re honest about which path you’re on.

The small bar is the part teams budget for, and the box underneath is the part they forget.

• Calling a hosted model API: the bottom of the band and sometimes under it, because the training data and the GPUs are already someone else’s problem.
• Fine-tuning a foundation model: the middle, where data preparation eats most of the money.
• Training a custom model: the top of the band and past it, once you count labeling and the people running each iteration.

The base app is the bigger number. The same guide puts a full build between $60,000 and $250,000 depending on complexity and platform, with maintenance running about 25% of build cost per year. People to do the ML work bill $50 to $250 an hour in North America, $40 to $180 in Europe, and $20 to $130 in India and Southeast Asia, junior to senior.

Since 2022, ML budgets have picked up a new line item: inference. Every prediction costs money, so the bill grows with usage. Managed pricing per million tokens sits, as of August 2026, at $0.10 in and $0.40 out on Gemini 2.5 Flash-Lite and $1.00 and $5.00 on Claude Haiku 4.5, both from the providers’ own pricing pages, and self-hosting costs $775 to $820 a month for an 8B model on one L4, or about $1,350 for a 70B on an A100, billed whether anyone sends it a request or not.

The machine learning app development budgets we watch go sideways are the ones that priced the build and forgot the run. A document-heavy product pays per page, every time. On BillDecoder, a bill audit pushes every page of a scanned statement through a model on each run, so the pricing had to be per-audit from the first week (per-seat would have lost money on the heaviest users).

Compliance and risk: when your model becomes a regulated device

In the US, the question that decides your regulatory life is what the model is for. Software intended to diagnose, treat, or drive a clinical decision is a medical device, and the intended-use language in your own marketing counts as evidence. A model that flags a suspicious lesion for a clinician sits on a different path from one that reminds a patient to take a pill. We have a full walkthrough of the FDA clearance path for health AI; the short version is that intended use and risk decide the pathway. Accuracy shows up later, in validation.

Models that keep learning carry their own wrinkle. The FDA expects a predetermined change control plan that says what the model is allowed to learn and how you’ll show it stayed safe, so retraining in production comes with paperwork of its own.

Once PHI touches a model, the vendor chain matters more than the model does. You need a BAA with whoever runs the inference and you need to know which subprocessors see the payload. BillDecoder takes a bill upload before the user has an account, so PHI arrives with no authenticated session behind it and the transport had to carry the compliance on its own.

Training data has a provenance problem that surfaces late. Scraped or licensed data you can’t document becomes a diligence problem, and by then retraining is the expensive way out.

The EU AI Act reaches further than most US teams assume. It applies when you place the system on the EU market, and it also applies when you sit outside the EU and the output your system produces gets used inside it, which covers plenty of US digital-health products with European users. Prohibited practices and AI-literacy duties have applied since February 2025, and obligations for general-purpose models since August 2025. The high-risk rules moved late: Regulation (EU) 2026/1744 entered into force on 27 July 2026 and pushed standalone high-risk systems out to 2 December 2027 and product-embedded ones to 2 August 2028. If someone told you August 2026 was the deadline, they were right until 6 days before it.

Real ML apps we’ve built

Three of our ML builds each answered the same question differently: how much of the intelligence do you own?

The route follows the task, and all three of these were the right call for theirs.

GaleAI trains its own. It reads physician notes and finds the CPT codes a human coder misses, with NLP handling the lookup, a deep neural network that sharpens with every scan, and OCR for handwriting. A one-month audit surfaced 7.9% more codes than the human coders had, which is $1.14M a year of revenue lost to undercoding. Coders now spend 97% less time on the task. The MVP took 1,100 hours across 9 months.

Allheartz is classical computer vision. The hard call was where to run it. Patients record a selfie video of an exam, the app pulls joint angles and range of motion out of the footage with TensorFlow and MoveNet, and a physiotherapist gets the numbers. We put it in the cloud, for the reason step 3 lays out. Clinics report up to 50% fewer in-person visits and up to 80% less clerical work.

BillDecoder trains nothing at all. Photograph a medical bill and it flags the errors line by line, then drafts a dispute letter, running Claude Sonnet 4.5 through Hathr.ai’s HIPAA-compliant transport with AWS Textract stitching the pages together. Discovery to launch across web, iOS and Android took 4 months. Hathr’s standard API wraps the model in a RAG layer tuned for general queries, and on a line-item audit that layer added noise to the arithmetic the whole result depends on. We bypassed it and preprocessed the math ourselves.

How Topflight approaches machine learning app development

Machine learning app development is most of what we do, for founders in healthcare and other regulated markets, and we’ve shipped both routes: trained models where the task demanded one, hosted models where it didn’t. Tell us what your app has to predict or decide and we’ll tell you which route we’d take, what it costs to build, and what it costs to run. Schedule a call with one of our experts.

Related Articles:

1. AI App Development: The Ultimate Guide
2. Machine Learning in Healthcare: Use Cases
3. Pose Estimation: The What, Why, When and How
4. Computer Vision in Medicine
5. AI in Medical Billing and Coding
6. Cost of AI in Healthcare
7. App Development Costs
8. How to Build a Chatbot Like ChatGPT
9. How to Create an NLP App
10. Artificial Intelligence in Healthcare

[Reviewed August 2026]