A useful idea.
A SaaS that lasts.

Understand the SaaS model

SaaS, or Software as a Service, is software accessed online whose provider operates and develops it. The customer buys access and an ongoing service. Subscriptions are common, but usage-based billing is also possible. A sales page or downloadable PDF alone is not a SaaS.

• B2B SaaS: you help a business complete a task. Identify the user, decision-maker and payer; they are not always the same person.
• Micro-SaaS: a deliberately narrow scope, often for a specific profession. A small product still needs security, support and maintenance.
• Unlike bespoke services, which mainly depend on your intervention, a SaaS provides repeatable software use; setup assistance can remain a separate service.

Find an idea worth subscribing to

Start with recurring work, a costly problem or awkward coordination. A useful starting point is an observable situation and people you can actually meet. A trend or AI feature does not prove demand.

• Ideas to explore: approval tracking for video studios, document collection for small agencies, renewal alerts for associations, maintenance tracking for tradespeople. These are hypotheses, not validated markets.
• Compare each idea: problem frequency, consequence of errors, current workaround, budget, access to buyers and data-handling complexity.
• Choose a narrow audience: “video studios waiting for client feedback” is more actionable than “all businesses”. Research competitors, spreadsheets and manual alternatives.

Validate before building

During interviews, ask what happened last time. “Would you use my tool?” often produces a polite answer. A recent example, anonymised document or demonstration of the current workflow teaches you more.

• Ask: how do you do this today? How often? Where do you lose time? What have you tried? Who approves spending? What would make you change your approach?
• Then offer a mock-up or a transparent manual service. Explain what exists, what remains manual and what is unavailable. A waiting list measures interest, not sales.
• Example internal rule, to adapt: proceed if several people describe the same problem and pilot users accept a trial under the stated conditions; otherwise narrow the audience or rethink the problem.

Define a genuinely usable MVP

The MVP is the first version that tests a hypothesis through real use. Reduce secondary features, never the controls that protect customers. Finish an end-to-end workflow before adding options.

• Fictional example — BriefPilot: a studio adds a preview link, invites its client and records approval. The MVP excludes video editing, general messaging and accounting.
• Essentials: create an account, join the correct workspace, complete the main task, understand errors, contact support and retrieve or export the agreed data.
• Write observable acceptance criteria: “an invitee sees only the authorised project”; “a declined payment does not grant paid access”; “a user can find their first project after signing in again”.

No-code, code or a hybrid approach?

Choose based on your skills, the data handled and what you must maintain. No-code can speed up a prototype; code provides more control but requires operational skills. No tool removes the provider’s responsibility.

• Before choosing a no-code platform, check data export, permissions, costs at higher usage, backups, API limits and migration options. Test how you can leave before committing the business.
• For custom development, choose a maintained framework you can debug, a suitable database and managed services where they reduce a real burden. Start simply; microservices are not a requirement for SaaS.
• With an AI coding assistant, review changes, keep secrets out of prompts, test permissions and errors, and preserve source history. Understanding and correcting the result is part of the job.

Understand what needs hosting

A starting architecture can combine an interface, application server, database and file storage. Long-running tasks go through a job queue. Email, payments and alerts use identified, monitored services.

• Separate development, staging and production. Use fictional test data, separate keys and documented production configuration.
• Isolate customers: verified identity determines the authorised workspace. Check access to objects, files, exports, caches and background jobs. An unguessable identifier is not an authorisation control.
• Set limits for file sizes, job volumes, API requests, storage and AI spending. One customer must not be able to exhaust all shared resources.

Permissions are checked by the server for every protected access.

Connect payments, subscriptions and access

A payment and an access entitlement are related but distinct states. A browser returning to a success page is not sufficient proof of payment. The server processes verified provider events and applies an explicit policy.

• Choose an understandable pricing unit: workspace, user, volume or usage. State price, limits, billing period, renewal and cancellation conditions before purchase.
• Test signed notifications, duplicate events, delays and failures. Retain processed event identifiers so redelivery does not duplicate an operation. Reconcile your state regularly with the provider.
• Document trial, active, overdue, scheduled cancellation, end of access and refund states. End-of-period cancellation retains access until the agreed expiry; data follows the stated retention policy.

Set a price and track contribution

Recurring revenue is not profit. Separate fixed costs, variable costs, acquisition, compensation, taxes and cash flow. A free trial or defaulting customer must not inflate a metric presented as paid recurring revenue.

• Initial budget: design, development, domain, hosting, database, storage, email, payments, monitoring, backups, professional advice and support. Include your time and non-monthly expenses.
• Fictional example: 30 customers at €29 excluding VAT per month represent €870 in MRR. With €4 variable costs per customer and €180 fixed costs, €570 remains before acquisition, compensation, taxes and other expenses.
• Under those assumptions, covering only the entered costs requires 8 customers: 180 ÷ (29 − 4), rounded up. This is neither a full profitability threshold nor guaranteed income.

Secure the service before opening

Prepare controls before using real data: authentication, permissions, input validation, session protection and workspace isolation. Managed components help, but configuration and permissions remain your responsibility.

• Use stronger authentication for sensitive accounts. Keep secrets outside the repository, restrict permissions and plan rotation. Verify session expiry and revocation.
• Test at least two customers and several roles: changed identifiers, file downloads, exports and API requests. Denial must be enforced by the server, not merely hidden in a menu.
• Define data-handling rules: purposes, necessary data, retention periods, rights, providers and possible transfers. Identify your role and the customer’s; processing agreements depend on that allocation.

Find your first SaaS customers

Return to people in the profession you understand. Your first goal is a qualified conversation, then successful use. Advertising amplifies a journey; it does not repair an unclear promise.

• Choose one main channel: professional network, a community that allows your post, an industry partner or targeted research. Prepare a limited list of relevant organisations and record the observed problem for each.
• Present a short demonstration using a realistic case. Offer a pilot with written duration, any price, support and exit conditions. Do not present a known brand as a customer or testimonial without permission.
• In France, professional outreach must relate to the recipient’s work, inform them and offer a simple opt-out. For individuals, prior consent is the general rule, with limited exceptions. Consult CNIL guidance before a campaign.

Build a page that makes people want to try

Within seconds, the page should explain who the software is for, what work it helps with and how to see it work. A real screenshot and annotated example are more useful than abstract promises.

• Structure: specific problem, observable result, demonstration, workflow, price and limits, FAQs, contact and next action. Show what exists today.
• VIFLY can support pre-sales: LinkHub gathers your demo and links; Forms collects enquiries; Booking offers appointments within its available options. Check their terms and prices. Building, hosting and billing your SaaS remain a separate project.
• For search visibility, an indexable page answers a specific intent with a descriptive title, example, internal links and canonical URL. Private pages remain private; avoid near-duplicate keyword pages.

Deliver the first useful result

Sign-up is not activation. Define the event showing the customer has experienced the first intended value. For BriefPilot, that could be a completed first approval, rather than merely an account created.

• Offer an example with fictional data, a short workflow and explanations at useful moments. Do not require full configuration before demonstrating value.
• With permission, observe a first session. Note where the person hesitates, rephrases or leaves. Fix the most common blockage before adding another feature.
• Prepare useful messages: welcome, invitation, password reset, payment and incident notices. Check deliverability and link consistency; distinguish service messages from marketing.

Measure what moves the product forward

Measure a complete journey: discovery, qualified enquiry, demonstration, activation, payment and renewal. Compare cohorts acquired in the same period; visits alone do not explain retention.

• MRR: normalised monthly recurring revenue, excluding VAT under your defined convention. Recurring annual payments are spread across months; one-off fees stay separate. Document trials, discounts and overdue accounts.
• Customer churn: customers lost during the period ÷ customers at its start. Do not confuse it with revenue churn. Separate new sales, expansions, downgrades and departures.
• CAC: acquisition spending within the chosen scope ÷ new paying customers attributed to it. With no customers, the calculation is undefined. Payback uses monthly contribution per customer; it ignores churn risk here.

Maintain the service with a clear routine

Maintenance is part of the product you sell. Assign every check to a person and a frequency suited to the risk. A green dashboard is useful only if alerts lead to action and the real journey works.

• Each operating day: review errors, availability, blocked jobs, payment failures, backups and unusual spending. Define who receives alerts, including during absences.
• Weekly: address repeated tickets, review updates and vulnerabilities, test sign-up and the main action, and check quotas and costs. Deploy with tests, staging, compatible migrations and a prepared rollback.
• At defined intervals and after major changes: restore a backup in an isolated environment, review access, test export and deletion, and review providers and documentation. A critical patch must not wait for a scheduled review.

Back up, restore and handle an outage

Define two objectives: RPO, the maximum time window of data loss you can tolerate, and RTO, the target time to restore service. They guide technical choices; they are not guarantees without measurement.

• Example internal objective: lose at most one hour of data and restore within four hours. Verify that backups, any logs, keys and procedures can actually support that scenario.
• Protect copies and separate them from the main system. Restore the database and files consistently, test integrity and permissions; the existence of a copy does not prove it is usable.
• During an incident: establish scope, limit impact, communicate without inventing a deadline, restore or roll back, verify, then document causes. If personal data is involved, promptly assess applicable obligations using CNIL guidance.

Retain customers and grow with focus

Retention starts with delivering the promise. Talk to active users, people who never activate and those who leave. Refunds and cancellations are situations to handle properly and opportunities to learn.

• Support: state realistic hours and response times, distinguish blocking failures from feature requests, retain context and document repeated answers. Arrange cover if you work alone.
• Roadmap: rank requests by problem, frequency, audience, impact and maintenance cost. One large customer should not silently turn the product into a fully bespoke project.
• Sustainable acquisition: publish documented cases with permission, useful guides and maintained integrations. Ask for honest reviews after demonstrated value; track referrals and disclose partnerships.

Move forward with a launch plan

This is an illustrative working rhythm, not a promise to launch within a month. If data access, security or problem validation takes longer, extend that stage before moving on.

• Week 1: choose an audience, conduct interviews, understand alternatives and write the promise. Decision: is the problem sufficiently specific and recurring?
• Week 2: mock-up, demo, MVP scope, technical choices and budget. Decision: will people in the target audience accept a pilot under the stated terms?
• Week 3: build the main journey and verify permissions, payment if needed and restoration. Week 4: support pilot users, measure activation and remove blockers. Decision: can access expand without degrading service?