A SaaS application (Software as a Service) is software you use through a browser or an API, while the provider takes care of the servers and the whole infrastructure. Access is usually paid for by subscription. So, what is a SaaS application in formal terms? Under the cloud computing definition from NIST (the US National Institute of Standards and Technology, 2011), a SaaS customer does not manage servers, networks, operating systems or storage — at most the application settings for their own account.
What SaaS is — a definition in plain words
In the SaaS model the application runs on the provider's infrastructure and you get access to it from different devices: through a browser (for example webmail) or through an API. You install nothing on a server, you do not update the database, you do not buy a licence "for ever".
NIST lists three cloud service models. They differ in how much stays with the provider and how much stays with you.
| Model | What you get | What you manage |
|---|---|---|
| SaaS | A ready-made application | Your account settings and your data |
| PaaS | A platform on which you run your own applications | Your application and its configuration |
| IaaS | Servers, networking and storage | The operating system and everything you install on it |
An important feature of SaaS: the provider's resources serve many customers at once (the multi-tenant model), and usage is measured — by the number of active accounts, for instance. Hence subscription or pay-per-use billing instead of a one-off licence.
How SaaS differs from desktop software and from a bespoke application
These are three different things, even though conversations often lump them together.
| Off-the-shelf SaaS on subscription | Software installed locally | An application built for your company | |
|---|---|---|---|
| Where it runs | On the provider's servers | On your computer or server | Wherever you decide (usually the cloud) |
| Who updates it | The provider | You or your IT department | The team maintaining the project |
| Range of features | The same for every customer | Depends on the licence edition | Exactly your process |
| Billing | Subscription for access | Licence (depends on the vendor) | Build cost + maintenance |
| What you have at the end | At most your exported data | Depends on the licence terms | Full rights to the code and the design |
Once a project at CodePort is paid for, full intellectual property rights to the code and design pass to the client, the code goes into their repository and we register the services in their company's name. With a subscription you pay every month for access — and that is all.
SaaS examples you know from everyday work
You do not have to look far. Most companies use several such tools without calling them by name:
- email and cloud storage in the browser, with accounts for the whole team,
- an online invoicing tool billed monthly,
- a CRM on subscription, where sales staff run their pipeline,
- a booking system for appointments or rooms, with a calendar and notifications,
- a task and project tool where you pay per active user,
- a platform for sending newsletters or for e-signing documents.
The common denominator: you log in, you have your own account and your own data, you pay on a recurring basis, and new features appear without any involvement on your part. That is exactly what SaaS applications are.
What a SaaS application is made of
Technically, SaaS is a web application with a few fixed building blocks. Each of them costs hours of work — which is why it pays to know exactly what you are ordering.
User accounts and roles
Registration, login, password reset, team invitations. Plus roles: company administrator, ordinary user, view-only account. The number of roles and permissions is one of the factors that push up the price of a web application the most.
Recurring payments
This is where the budget grows. A one-off payment means, in practice, plugging in a payment gateway. A subscription means pricing plans, trial periods, plan changes mid-month, failed card charges, invoices and payment history. Every one of these cases has to be handled and tested separately.
Customer panel and admin panel
Your customer sees their own data, their own invoices and their own settings. You see every account, payment, support ticket and statistic. In practice that is two applications in one — and the second one is easy to overlook when estimating. That is how it works in the admin panel for ZAC Group, for example.
Many customers on one installation
In SaaS, a single installation serves many companies, and their data must be kept separate. This is an architectural decision worth making at the start, because changing it later means rebuilding the database and the access logic.
Integrations through APIs
Users will want to connect your tool to what they already use: an accounting system, CRM, ERP, a payment gateway. Sometimes you also need your own API so that others can plug into you. You will find more about what needs to be prepared on the page about system and API integrations.
Maintenance
SaaS does not end on launch day — in this model you are the one responsible for availability. Monitoring, backups, library and system updates, small fixes. Typically 5 – 15 hours a month.
You will also recognise items from this list in projects that are not SaaS. The HunterValley IT job platform has two account types — candidate and company — with Google sign-in, profiles and a job-posting builder. The ZAC Group investment platform panel has clients, transactions, client requests, a team task module and role-based login. Accounts, roles and an admin panel are the foundation in a subscription application too.
An off-the-shelf SaaS subscription or your own application?
If your process looks the same as in thousands of other companies, a ready-made subscription tool will do the job and will be cheaper. There is no point building invoicing or a simple booking calendar from scratch.
A bespoke application makes sense in four situations:
- you pay for several tools that somebody in the company stitches together by hand,
- the process is your advantage and won't fit into someone else's template,
- you need integrations that an off-the-shelf tool doesn't allow,
- you want to sell your own product as SaaS.
The fourth point is qualitatively different from the rest. In the first three you are building a tool for yourself. In the fourth you are building a product that has to handle other companies, other people's payments and other people's data — and that is a fully fledged web application with a panel and recurring payments.
How to build a SaaS of your own, step by step
The most common mistake at the start is scope. The first version gets every feature anyone thought of over six months, and the budget runs out before launch.
An MVP (Minimum Viable Product) is the smallest version of a product that solves a real user problem — a working product stripped back to one key function. The test is simple: if removing a feature does not stop the product from solving the main problem, that feature does not belong in the MVP. You will find more on this in the article on whether to start with an MVP or a full product.
This is what work on such a project looks like at CodePort:
| Stage | What happens | How long it takes |
|---|---|---|
| 1. Conversation and estimate | We agree the scope; we reply within one working day | Price range and schedule within 2 – 3 working days, free of charge |
| 2. Prototype | A clickable mock-up, before the first line of code is written | Depends on the number of screens |
| 3. Sprints | A working version every 1 – 2 weeks, not a presentation | Until the scope is complete |
| 4. Launch and further development | Publication, monitoring, further iterations | Ongoing |
A platform MVP reaches the market in 2 – 4 months. We bill projects in stages, work on the basis of a contract and an NDA, and mostly remotely.
On the technology side, for web applications we use React, Next.js, Vue and TypeScript on the front end, Node.js, Python or PHP on the back end, PostgreSQL, MySQL and MongoDB databases, plus AWS, Docker and CI/CD for deployments. We choose the stack to suit the project, not the other way round.
SaaS and GDPR — who you are when you hold other companies' customer data
If companies keep their own customers' data in your application, you are usually the processor and your client is the controller. Under the GDPR (EU Regulation 2016/679) such processing takes place on the basis of a contract setting out, among other things, the subject matter, duration, nature and purpose of the processing, the type of data and the categories of data subjects.
That contract also brings specific obligations: you process data only on the controller's documented instructions, you do not engage another processor without their written consent, and when the service ends you delete or return the data — depending on their decision.
In practice this means that exporting and deleting account data has to be planned as a product feature, not a manual operation on the database. Confirm the scope of your obligations with a lawyer or data protection officer — CodePort does not provide legal advice. If the product processes health data, separate requirements apply — we cover them in our article on medical apps, GDPR and MDR.
SaaS development cost
We bill by the hour: €46/h net (excl. VAT) for development, €35/h net (excl. VAT) for design. Indicative project price ranges look like this:
Euro amounts converted at the NBP mid-market rate of 14 September 2026 (€1 = 4.3391 zł) and rounded. We invoice in PLN.
| Scope | Price range | Time |
|---|---|---|
| A simple application or panel | €4,150–10,400 net (excl. VAT) | 6 – 10 weeks |
| Platform / product MVP with modules, integrations, payments and roles | €9,200–23,000 net (excl. VAT) | 2 – 4 months |
| Extensive system | from ca. €23,000 net (excl. VAT) | built in stages |
An illustrative example, not an offer: a platform MVP with payments and two account types comes to 300 development hours × €46 = €13,800 net (excl. VAT) plus 60 design hours × €35 = €2,050 net (excl. VAT), giving €15,900 net (excl. VAT) in total.
On top of that come post-launch costs: servers and infrastructure from a few dozen to a few hundred euros a month, depending on the number of users and the volume of data, plus technical support of 5 – 15 hours a month, that is €230–690 net (excl. VAT). The biggest influences on price are: the number of roles and permissions, integrations with external systems, recurring payments and the size of the admin panel. Full tables and hour breakdowns are in the article on how much a web application costs.
If you have an idea for a SaaS application of your own, check the indicative price range in the cost calculator or describe the scope in the project brief builder — we will prepare a detailed estimate with a schedule free of charge within 2 – 3 working days.
Frequently asked questions
What are SaaS applications, put as simply as possible?
They are programs delivered as a service: they run on the provider's servers, you use them through a browser or an API, and you pay for access, usually by subscription. You do not buy a licence on a disc and you are not responsible for updates.
What does SaaS pricing usually look like?
You usually pay a subscription — for each active user account per month, for example — or for actual usage. NIST lists "measured service" as one of the characteristics of the cloud: usage is metered, for instance by the number of active accounts. With your own product, the number of plans and exceptions in the price list translates directly into hours of work on recurring payments.
Does CodePort build SaaS systems with recurring payments?
Yes. SaaS systems with user accounts, roles, recurring payments and a customer panel are one of the three types of web application we focus on.
How long does it take to build a SaaS application of your own?
A platform MVP reaches the market in 2 – 4 months, a simpler panel in 6 – 10 weeks. Along the way you see a working version every 1 – 2 weeks, so you can adjust the scope as you go rather than only at the end.
Who owns the code of a bespoke SaaS application?
Once the project is paid for, full intellectual property rights to the code and design pass to the client, and the code goes into their repository. The services the application uses are registered in the client's company name.