---
title: "Web App, SaaS & MVP Development Services — Dardo"
description: "Web app, SaaS and MVP development: accounts and roles, payments verified on the server, an admin view and customer domains, scoped to a first version."
url: "https://dardo.studio/en/services/web-app-development/"
language: "en"
translation: "https://dardo.studio/es/servicios/desarrollo-de-software-a-medida/"
updated: "2026-10-08"
---

# Web app, SaaS and MVP development

Dardo builds web apps, SaaS products and MVPs for founders and companies that need software their customers sign in to, pay for and rely on, not a marketing website. We scope the first version around one core workflow, then design, build, test and launch it with accounts, permissions, payments, an admin view and analytics, on code and accounts you own.

By Dardo editorial team · Updated 8 Oct 2026 · 9 min read

[Message us on WhatsApp](https://wa.me/573163373216?text=Hi%20Dardo%2C%20I%27d%20like%20a%20proposal%20for%3A%20Web%20app%2C%20SaaS%20and%20MVP%20development) · [Read in Spanish](https://dardo.studio/es/servicios/desarrollo-de-software-a-medida/)

## What a web app or MVP project includes

We shape the engagement around the actual brief. The proposal identifies which of these deliverables are included, who supplies the inputs and how each one is accepted.

- First-version scope: core workflow, roles and what waits
- Key screens designed with empty, loading and error states
- Data model, server-side access rules and tests that try to break them
- Accounts, roles and team invitations
- Payments or subscriptions confirmed by verified provider callbacks
- Admin view, product analytics events and error monitoring
- Deployment, documentation and handover of the repository and accounts

## Web app, website or product design first?

Choose this when customers or staff need to sign in and complete work in the product: buy, book, submit, approve or manage something. If you need a site that explains and sells your offer, Web Development is the better fit. If the workflow is not settled yet, start with Product Design and build once the key screens have been tested with users.

## How a first version gets built

We start with a scoping phase: the users and roles, the one workflow the first version must complete, the data each step creates and the decisions that change cost, such as payments, integrations and permissions. The output is a written scope, clickable key screens and a release plan that names what is deferred.

Then we build in short cycles on a staging environment you can use. The first milestone is a thin slice of the core workflow running end to end, with real sign-in and real data rules, before the remaining screens are filled in. Launch includes production monitoring, a rollback path and handover of the repository, hosting, database, payment and analytics accounts in your name.

## What belongs in the first version of an MVP?

A first version needs everything required for a real user to complete one workflow, and nothing that only matters at a scale you have not reached. In practice that is five things: accounts with the roles the workflow requires, the core workflow itself, an admin view so your team can see and fix records without a developer, payments if the business model charges from day one, and analytics events that show where users stop.

Defer what can be done by hand or bought later: a native mobile app, single sign-on for enterprise customers, a configurable permissions matrix, a second integration, in-app chat and reports nobody has asked for. Each deferred item still gets a line in the scope so the data model leaves room for it.

Most products are assembled from familiar modules. Two deserve a note: booking and scheduling, and a lead pipeline for a small business that tracks inquiries by hand today. Both look simple and hide decisions about time zones, statuses and ownership that are cheaper to settle on paper.

__What belongs in the first version of an MVP?__
| Module                    | What it needs                                                                               | Decide before building                                                 |
| ------------------------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| Accounts and roles        | Sign-up, sign-in, recovery, and a role check on every server request                        | Which roles exist, and can one person belong to several organizations? |
| Team invitations          | Expiring invite links, seat counts, ownership transfer, removal that revokes access at once | Who can invite, and what happens to a removed member's records?        |
| Billing and plans         | Hosted checkout or subscriptions, verified callbacks, plan limits enforced on the server    | What each plan includes, and what happens when a payment fails?        |
| Booking and scheduling    | Availability rules, time zones, buffers, a double-booking guard, reminders, rescheduling    | Who sets availability, and is a slot held while the customer pays?     |
| Inquiry and lead pipeline | Spam-protected form, statuses from new to won or lost, assignment, source, consent record   | Which statuses your team really uses, and where a lead goes next?      |
| Admin and reporting       | Search, record history, manual corrections, exports                                         | Which numbers the team reviews each week, and who may edit records?    |
| Custom domains            | Hostname onboarding, DNS verification, certificate status, plan checks                      | Which plans include a domain, and which host limits apply?             |
| Audit log                 | Append-only record of who changed what and when                                             | Which actions your customers or auditors must be able to trace?        |
| Notifications             | Email and in-app messages, templates, delivery log, user preferences                        | Which events notify whom, and which can be switched off?               |

## Which stack does Dardo use, and when does it choose differently?

Our default is TypeScript end to end: Astro for server-rendered pages and interactive islands, Cloudflare Workers for hosting and APIs, Cloudflare D1 or Postgres for data, and PostHog for analytics and experiments. Superame runs on Astro with its ranking stored in Neon Postgres. One language and one deployment target keep a small product simple to run and to hand over.

We choose differently when the product asks for it. A dense interface that stays open all day can justify a client-side React application, as in the Shiimain prototype. Long-running jobs, heavy data processing or an in-house team that already works in another framework also change the answer. If your developers will own the code after launch, their stack usually wins.

Access control is the first thing we test. OWASP's Top 10:2025 keeps Broken Access Control at number one and reports that every application it tested had some form of it. We enforce permissions on the server for every request, deny by default, scope each query to the signed-in user's organization and write automated tests that try to read another customer's records.

## How should payments work in a web app?

The payment provider confirms a payment on the server; the browser returning from checkout never does. Superame, a public project leaderboard in Dardo's published work, shows the pattern. Buyers pay on Dodo Payments' hosted checkout, so card details never reach the app. The provider then sends a signed callback, and the server verifies the signature and checks the payment details before it adds credit.

Refunds and disputes follow the same path. Each provider event is applied once, so a callback that arrives twice, late or out of order cannot add or remove credit twice. Superame publishes no adoption or revenue figures; it is evidence of how the payment logic is built, not of sales.

- A buyer who closes the tab before the redirect is still credited when the callback arrives.
- A replayed or forged callback is rejected.
- A refund or dispute reverses exactly what the original payment granted.
- Plan limits are checked on the server, not only hidden in the interface.
- Test and live keys are separate secrets, never stored in the repository.

## Let your customers use their own domains

B2B SaaS customers often want the product on their own address, such as portal.theircompany.com. Cloudflare for SaaS handles this with custom hostnames: the Free, Pro and Business plans include 100, each additional hostname costs $0.10, and the maximum is 50,000. Wildcard custom hostnames are Enterprise-only.

Your customer adds a CNAME record pointing to your target. Using an A record to point to that target, which a root domain would need, is not supported by default, and apex proxying is an Enterprise add-on, so most customers should use a subdomain. Certificates are validated by HTTP, TXT or email, or with Delegated DCV, a one-time record that lets Cloudflare renew them automatically. They are issued by Let's Encrypt, Google Trust Services or SSL.com.

The product work around it matters as much: only paid plans can connect a domain, an onboarding screen shows the exact record to add, the verification status explains pending and failed states in plain language, and monitoring alerts your team when a certificate cannot renew because a customer changed their DNS. Other hosts set different limits: Vercel allows 50 domains per project on Hobby and unlimited on Pro and Enterprise, with soft limits of 100,000 and 1,000,000; Netlify recommends no more than 50 domain aliases per site.

## Questions before you choose

**What drives the cost of a web app or MVP?**

Cost follows the number of roles, the complexity of the core workflow, payments, integrations and how much existing data must be migrated. Permissions and states matter more than screen count: one screen with five roles and an approval step is more work than five read-only screens. We price a written scope after the scoping phase, not a per-feature rate.

**How long does it take to build a first version?**

It depends on how settled the workflow is, how quickly decisions and content arrive, and whether third parties such as a payment provider or a client's IT team must approve access. The proposal sets milestones starting with a working slice of the core workflow. The date for the full release is fixed once that slice is accepted.

**Can Dardo take over an existing codebase?**

Yes, after an audit. We review the repository, dependencies, data model, access checks, deployment and who controls each account, then report what can stay, what must be fixed first and whether repair or a rewrite makes more sense. We do not promise to keep or replace a codebase before reading it.

**Do you build native iOS and Android apps?**

No. Dardo builds for the web, including installable web apps that open from a home-screen icon. When a product depends on device features the browser does not expose, app store distribution or heavy offline use, a native app is the better fit and we will say so. The web app and its API can still serve as the backend for a native team.

**Who owns the code and the accounts?**

You do. The repository, hosting, database, domain, payment provider and analytics accounts are created in your name or transferred at handover, and the proposal lists any licensed dependency that cannot be transferred. Dardo keeps only the access you grant for support.

**What do you need from us?**

A decision-maker who can answer scope questions within days, access to the systems the product must connect to, and real examples of the data and documents the workflow uses. Open the payment provider account in your company's name early, because providers review a business before enabling live payments.

**What happens after launch?**

The proposal can include a support period for bugs, monitoring and small changes while real users arrive. After that, further development is agreed as a monthly scope or a new project. Security updates and dependency upgrades are not optional, so they need a named owner either way.

## Sources & further reading

Sources behind this page, with further detail from the original publishers.

- [OWASP Top 10:2025, A01 Broken Access Control](https://top10.owasp.org/2025/A01%5F2025-Broken%5FAccess%5FControl) · top10.owasp.org
- [Cloudflare for SaaS: plans and custom hostname limits](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/plans/) · developers.cloudflare.com
- [Cloudflare for SaaS: getting started (CNAME target and A records)](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/) · developers.cloudflare.com
- [Cloudflare for SaaS: certificate validation methods](https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/security/certificate-management/issue-and-validate/validate-certificates/) · developers.cloudflare.com
- [Cloudflare: certificate authorities](https://developers.cloudflare.com/ssl/reference/certificate-authorities/) · developers.cloudflare.com
- [Vercel: limits (domains per project)](https://vercel.com/docs/limits) · vercel.com
- [Netlify: add a domain alias](https://docs.netlify.com/manage/domains/configure-domains/add-a-domain-alias/) · docs.netlify.com

[Dardo](https://dardo.studio/) · [Services](https://dardo.studio/en/services/) · Web apps & SaaS

## Related work & studies

[![superame.lol website, a Dardo project](https://dardo.studio/work/superame-1.webp?v=34a51b35f537) · In practice / Selected work · **superame.lol** · See the project](https://dardo.studio/en/work/superame/)

## Plan your first version

Describe the workflow your customers or staff must complete and who takes part in it. We reply with the questions that decide scope, and we say plainly if a tool you can buy already does the job.

[01 · **Inspect relevant work** · superame.lol](https://dardo.studio/en/work/superame/) · [02 · **Compare adjacent scope** · Product design](https://dardo.studio/en/services/product-design/) · [03 · **Discuss your brief** · Request a scoped proposal in your language](https://dardo.studio/en/contact/?service=web-app-development)

## Keep exploring.

- [![superame.lol — website preview](https://dardo.studio/work/superame-1.webp?v=34a51b35f537) · Case study · **superame.lol — web design case study**](https://dardo.studio/en/work/superame/)
- [Service · **Product design and UX/UI for web apps and SaaS**](https://dardo.studio/en/services/product-design/)
- [Service · **Custom client portal development**](https://dardo.studio/en/services/client-portal-development/)

- [Service · **Data visualization design and dashboard interfaces**](https://dardo.studio/en/services/data-visualization/)
