Types of software development: a complete overview

Software development splits into a handful of main types: web, mobile, custom business and enterprise software, SaaS products, AI and data, cloud and DevOps, security, integration, and specialist fields such as embedded systems and games. Most real projects combine several of them: a typical product has a web frontend, a backend, a database, a mobile app and a cloud platform underneath, built by people with different skills.

This overview explains what each type involves, what it produces, the kind of team it needs and the questions that decide which ones your project actually requires. Each section links to a deeper guide, so treat this page as the map and the linked guides as the detail.

Why the categories matter when you are buying software

Labels like ‘web development’ or ‘AI development’ sound like marketing, but they map to real differences in skills, tools, risk and cost. A team that is excellent at native iOS apps may be mediocre at data pipelines. A security review needs different people from a user interface redesign. If you know which types of work your project contains, you can brief suppliers precisely, compare proposals like for like, and spot when a quote is missing something important, such as the backend behind a mobile app or the testing behind a payment flow.

It also helps to know that the categories overlap and are sliced in different ways. The IEEE Computer Society’s Software Engineering Body of Knowledge (SWEBOK) organises the discipline by activity (requirements, architecture, design, construction, testing, operations, maintenance, security and so on), while the market sells it by platform and purpose. Both views are useful. The activities are the same whatever you build; the platform and purpose decide which specialists you need.

Four ways to slice the field

• By where it runs: browser (web), phone or tablet (mobile), desktop, servers and cloud, or devices (embedded and IoT).
• By layer: the frontend people see and touch, the backend that holds the rules and data, and the infrastructure that runs both.
• By purpose: a product you sell (SaaS, apps), a tool your own staff use (internal and enterprise software), or plumbing that connects systems (integration and APIs).
• By lifecycle stage: a new build, work on existing software (maintenance, modernisation, migration), or keeping it running (operations and support).

The main types at a glance

Web development

Web development is the largest category and the one most businesses meet first. It covers anything delivered through a browser: marketing sites, customer portals, booking systems, internal dashboards and full web applications. The browser is the most widely available runtime there is, which is why many products start on the web and add mobile apps later, if at all.

Inside web development the useful distinction is between frontend (the interface: layout, interaction, accessibility, performance in the browser) and backend (the server: business rules, data, authentication, integrations). Full-stack engineers work across both. The Stack Overflow 2025 Developer Survey shows how common that is: 27% of respondents described themselves as full-stack developers, against 14.2% back-end and 4.3% front-end. Our guide to frontend vs backend development explains where the line sits and why it matters for hiring.

Two things separate good web work from adequate web work. The first is accessibility: WCAG 2.2, the current W3C Recommendation, sets out testable criteria under four principles (perceivable, operable, understandable, robust), and in many markets it is now a legal expectation rather than a nice extra. The second is performance on real devices and networks, which decides whether people stay. For a full breakdown of what web projects include, see what are web development services.

Mobile app development

Mobile development produces apps for iOS and Android. It brings constraints the web does not have: app store review, device permissions, offline behaviour, push notifications, battery limits and a long tail of screen sizes. It also brings platform rules that change every year. Google Play, for example, requires new apps and updates to target a recent Android API level, so an app that nobody touches eventually becomes unavailable to new users on newer devices. Mobile software is never really finished.

Almost every app also needs a backend: an API, a database, authentication and an admin panel. When you compare mobile quotes, check that this part is included, because it is often half the work. The bigger strategic choice is how to build the app itself:

Our guides to mobile app development services and native vs cross-platform development go through the trade-offs in detail.

Custom business software and enterprise applications

Custom business software is built for one organisation’s own processes: an operations platform, a quoting engine, a field-service app, a claims workflow, a compliance tool. Enterprise application work is the same idea at larger scale, often extending or connecting big platforms such as ERP and CRM systems rather than replacing them.

The value of custom software comes from fitting the way you actually work, especially where that way of working is what makes you better than competitors. Its cost is that you own it: you pay to build it and you pay to keep it healthy. That trade-off is the subject of our guide to custom software vs off-the-shelf, and the full process is covered in the custom software development guide.

SaaS and product development

SaaS (software as a service) is software you sell on subscription to many customers, who use it over the internet. NIST’s definition of cloud computing treats SaaS as one of three service models, alongside platform (PaaS) and infrastructure (IaaS) as a service. From a development point of view, SaaS adds work that internal tools do not need: multi-tenancy (keeping each customer’s data separate), self-service sign-up, subscriptions and billing, usage limits, audit trails, and a release process that never takes every customer down at once.

Product development is also a different discipline from project delivery. A project ends; a product is shaped continuously by user feedback, analytics and commercial goals. Our SaaS development guide covers how to build one, and how to scope an MVP without wasting budget covers the first release.

E-commerce development

E-commerce sits between web development and integration. Most stores today run on a platform (hosted or open source) and the development work is in theming, checkout customisation, headless storefronts, and connections to payment providers, inventory, ERP, shipping and marketing tools. Fully custom commerce engines are rarely justified unless the business model is unusual, such as complex B2B pricing or marketplaces. See the e-commerce software development guide for when to use a platform and when to build.

AI and machine learning development

AI development now covers three quite different kinds of work, and it pays to know which one you are buying:

• Classical machine learning: models trained on your own data to predict, classify or detect, such as demand forecasting, fraud scoring or churn prediction. Success depends on data quality and volume more than on the algorithm.
• Generative AI features: large language models used for search over your documents, drafting, summarising, extraction or chat. Here the model is usually bought, and the engineering is in retrieval, prompts, guardrails, cost control and, above all, evaluation.
• Agents and automation: systems where a model plans and calls tools to complete multi-step tasks. Powerful, but they need tight permissions, human checkpoints and audit logs.

All three need the same discipline that ordinary software needs, plus a way to measure quality that is honest about failure. NIST’s AI Risk Management Framework organises that work into four functions (govern, map, measure, manage) and is a sensible checklist even outside the US. To go further, read what are AI development services, how to add AI to your product and our piece on what decides answer quality in RAG systems.

Data engineering and analytics

Data engineering moves data from where it is created to where it is useful. It covers pipelines that extract data from operational systems, warehouses or lakehouses that store it in an analysable shape, data quality checks, and the reporting and business intelligence layer on top. It is also the foundation most AI work quietly depends on. If your team spends Monday mornings copying numbers between spreadsheets, the fix is usually data engineering, not a new application. Our data engineering page describes what that work looks like in practice.

Cloud, DevOps and platform engineering

This category is about how software is built, shipped and run rather than what it does. Cloud engineering designs and manages the infrastructure, ideally as code. DevOps covers the pipelines that test and deploy every change, plus monitoring, alerting and incident response. Platform engineering packages all of that into self-service tools for other developers.

The clearest yardstick here comes from Google’s DORA research programme, which tracks five software delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. They measure throughput and stability together, which stops a team from buying speed with outages. Our guides to DevOps services and cloud migration services cover the two most common engagements in this area.

Security engineering

Security is both a type of work in its own right (threat modelling, penetration testing, security architecture, incident response) and a quality every other type must have. The OWASP Top 10:2025 is the best-known list of web application risks; broken access control sits at the top, followed by security misconfiguration and software supply chain failures. NIST’s Secure Software Development Framework describes the practices that keep those risks out of the code in the first place.

The practical lesson for buyers: security is cheapest when it is designed in, and most expensive when it is bolted on after a breach or a failed customer audit. Our cybersecurity services guide explains what to buy and when.

Integration, APIs and middleware

Most organisations already own plenty of software. Integration work makes it behave like one system: syncing customers between CRM and billing, pushing orders from a store into an ERP, exposing internal data through a well-documented API for partners. It is unglamorous and often underestimated, because every connected system brings its own data model, rate limits, error behaviour and change schedule. Read what is system integration for the main patterns and their trade-offs.

Embedded, IoT, games and other specialist fields

A few types of development are specialised enough that general software teams should be honest about whether they can do them well:

• Embedded and firmware: software that runs on microcontrollers inside devices, with tight memory, power and real-time constraints, often written in C, C++ or Rust.
• IoT: fleets of connected devices plus the cloud services that provision, update and collect data from them. The device side and the cloud side need different skills. See IoT.
• Games and real-time 3D: engines such as Unity and Unreal, graphics programming, physics, and a production process closer to film than to business software.
• Extended reality: AR and VR experiences for training, retail or visualisation, built on the same real-time 3D foundations.
• Desktop software: still the right answer for some professional, industrial and offline tools, often now built with cross-platform frameworks.

Work on existing software: maintenance, modernisation and testing

A large share of software development is not new building at all. SWEBOK treats maintenance as its own knowledge area, and the standard way to divide it is into four kinds of change: corrective (fixing faults), adaptive (keeping up with new operating systems, browsers, regulations and dependencies), perfective (improving features and performance) and preventive (refactoring to stop future problems). Budgets that only plan for the first one are always surprised by the other three.

Modernisation is the bigger version: moving an ageing system to supported technology, splitting a monolith, or replacing it piece by piece while it stays in use. Quality assurance runs through all of it, from automated tests in the pipeline to exploratory testing before releases. Our guides to software maintenance and support and legacy software modernisation cover both, and quality assurance describes the testing side.

Ways of getting it built: in-house, outsourced or hybrid

The type of development is one decision; who does it is another. You can hire an in-house team, outsource a whole project to a studio or agency, add external engineers to your own team (staff augmentation), or mix the three. The right answer depends on how central the software is to your business, how fast you need to move and whether you can recruit and manage engineers well.

If you are going outside, our guides on software development outsourcing and how to choose a software development company walk through the models, risks and selection process. For budgeting, see how much custom software development costs.

How to work out which types your project needs

Work from the problem outwards rather than from the technology inwards. These questions usually reveal the shape of a project within an hour:

1. Who uses it, and where? Staff at desks suggests a web app; customers on the move suggests mobile; machines talking to machines suggests APIs and integration.
2. What existing systems must it talk to? Every connection adds integration work and risk. List them early.
3. Where does the data come from, and who needs to see it afterwards? If reporting is a goal, plan the data layer from the start.
4. Is it a product you will sell, or a tool you will use? Selling it means SaaS concerns: multi-tenancy, billing, onboarding and support.
5. What could go wrong, and how badly? Personal data, payments and health information raise the security, privacy and compliance bar.
6. Does a model need to make judgements? Only then is AI part of the scope, and it needs a plan to measure quality.
7. How long must it live, and who will look after it? That decides how much to invest in tests, documentation, automation and handover.

Most projects are not one type of software development. They are a web app, a backend, a database, two or three integrations and a deployment pipeline, and the gaps between those pieces are where budgets go wrong.

When you should not build anything

An honest overview should also say when none of these types is the right answer. If a well-supported off-the-shelf product covers most of your needs, and your process is not what differentiates you, buy it and spend your effort elsewhere. If the problem is a manual workflow used by three people a few times a month, a spreadsheet, a form tool or a low-code automation may be enough. If you cannot yet describe who the users are and what they will do differently, the right next step is research, not development.

Custom development earns its cost when the software is close to how you make money, when no product fits without painful workarounds, or when owning the system gives you control you need over data, security or roadmap. Our comparison of custom software vs off-the-shelf has a checklist for that decision.

How Authect approaches this

Authect is a founder-led software development studio. Our core is software development, with web, SaaS, mobile (iOS and Android), AI and security as the fields we work in most. Because most projects span several of the types above, every project is led by a senior engineer who owns the whole shape of it, from the interface to the infrastructure, and you talk directly to the founders who build it rather than to a salesperson.

We use AI to speed up delivery, and an engineer reviews every line before it ships. Teams are small. You own the code, infrastructure and designs from day one, with no lock-in. If you are not sure which kinds of development your idea needs, tell us about it and we will help you map it, even if the honest answer is that you should buy something instead.