Website
Present an offer, be found on Google, receive contact or quote requests. No accounts, little logic.
Build With Me / Web
Build your web product with me.
A site that brings in requests, an app your team uses every day, a SaaS customers pay for: each product has its own right way to be built.
To build a web product, start from the problem and the users, not the technology. A presentation site is usually best made with a site builder; a standard store, with a hosted commerce platform; custom code pays off when the product has accounts, per-user data, business rules or integrations no tool handles. Then the order matters: data model, authentication, the main flow, payments, and a verified production launch.
Checked on
In brief
- For
- Founders, freelancers, teams and developers who want to build a web product.
- Covers
- Websites, web apps, SaaS, PWAs, marketplaces, stores, client portals, internal tools, booking.
- Principle
- The simplest tool that meets the need — a site builder when it is enough, code when it is needed.
- Build order
- Data → access → main flow → payments → verified production.
- What this page does not do
- No automatic quote, no invented price: cost depends on scope.
Three ways to build
Learn, build it together, or have it built.
01 · Learn and buildGuided offer — An existing Bynilson product, on published terms.
Learn and build it yourself
Build School is Bynilson’s paid programme for building a web product with a coding agent and proving it is production-ready: a staged path, templates, ShipCheck. Before buying anything, the free resources on this page and the SaaS Starter Kit checklist are enough to get started.
Build School · Starter Module →CHF 249The complete path to build a web product with a coding agent, at your own pace.SaaS Starter Kit — free checklist →This page’s guide, step by step →Build With Me learning paths →Guide “Build with AI or delegate?” →CHF 39To decide what you can build yourself with AI (in French).
02 · Build it togetherGuided offer — An existing Bynilson product, on published terms.
Build it together
You keep control of your code and your repository; Bynilson reviews, unblocks and prioritises. Two formats already exist in Build School: Cohort Build (a cohort, feedback, repository review) and Premium Mentoring (architecture and security review, debugging on your repository, by application). Written collaboration — instructions, annotated screenshots, captioned recordings — is a first-class path: no call is required.
Build School · Cohort Build →CHF 799The same path in a cohort, with a review of your project and your repository.Build School · Premium Mentoring →from CHF 2’000Architecture, security and launch reviews on your real project — by application.Describe your project for guidance →Reviewed case by case. Written collaboration available, no call required.
03 · Have it builtGuided offer — An existing Bynilson product, on published terms.
Have it built
For a product to build or rebuild, the project qualification tells you in six questions whether it fits a Bynilson engagement; a minimum engagement applies, and the answer says so plainly when a project is below it. For an existing app that breaks, Code Rescue; to check before a launch, Launch Rescue.
Have your product built →from CHF 20’000Delivery engagements from CHF 20’000, fixed price after scoping.Product & architecture diagnostic →CHF 2’400CHF 2’400, delivered in 7 working days, credited against a build.An existing app that breaks? →Code Rescue fixes it, Launch Rescue checks it before launch.
The products
Which web product are you building?
Ten product shapes, the sensible way to build each one, and the classic trap. The right starting point is often simpler than expected.
Web application
Signed-in users, data that belongs to them, business rules: software that runs in the browser.
SaaS
Customers create an account and pay a subscription to use your software. The product has to run without you.
Progressive web app (PWA)
A web app people can install on their home screen, which can partly work offline, without going through a store.
Marketplace
Two kinds of users meet: sellers or providers list, customers buy or book.
Online store
Sell products: catalogue, cart, payment, shipping, returns, VAT.
Client portal
Your clients sign in to upload documents, follow a case, find their invoices.
Internal tool
Replace spreadsheets, emails and copy-paste with a team tool that has roles and a history.
Booking platform
Slots, availability, confirmations, reminders and cancellations.
Member-only content
Lessons, courses, templates or resources available after payment, with each person’s progress.
The approaches
Site builder, no-code or custom code?
There is no universal right answer. There is the simplest tool that meets your need today, and the limits that will make you switch tomorrow.
- Site builder
- Pages, content, forms, hosting included. The right choice for a presentation site or a blog you want to edit yourself. Limit: little or no logic of its own, no per-user data.
- No-code
- Visual tools to build a database, forms, automations, sometimes a full app. Excellent to validate an idea or equip a team quickly. Limits: complex rules are hard to test, costs grow with usage, platform dependency, and data export should be checked before committing.
- Low-code
- A visual platform where you add code where it stops. Useful for internal tools. Limit: you carry both the platform’s constraints and the maintenance of the added code.
- Custom code
- You own the code, the data model and the hosting. The right choice when the product carries business rules, sensitive data, integrations or a scale tools cannot handle. Limit: it has to be built, tested and maintained — alone, with help, or by delegating.
What usually pushes towards custom code: rules you must be able to test and version, data you must control (where it is hosted, who can access it), an integration no connector offers, or a platform cost that exceeds that of maintained code. What should hold you back: a need that is still unclear. Validating with a simple tool costs less than rebuilding a poorly scoped product.
Site builder or custom development?Compare before choosing →
No-code or custom development?Compare before choosing →
The technology
Which technology, for which need?
The same stack is not pushed onto every project. Technology is chosen from the requirements — and from who will maintain the product afterwards.
| Requirement | Reasonable options | When it is not the right choice |
|---|---|---|
| Rich, interactive interface | React with TypeScript; a framework such as Next.js for server rendering and routing | A content site with no interaction: a site builder or a static site generator is enough |
| Pages found on Google | Server rendering or static pages, generated metadata and sitemap | A fully private app behind a login: SEO only matters for public pages |
| Server logic and API | Node.js (the framework’s API routes or server actions), or another server language your team knows well | If your team knows Python, PHP or another ecosystem well, the best stack is the one it can maintain |
| Relational data | PostgreSQL, directly or through a managed service such as Supabase (database, auth, storage) | Data with no relations or complex queries, or a volume a no-code tool already handles |
| Payments | Stripe (Checkout for payment, webhooks for confirmation) | A standard store: the commerce platform already includes payment |
| Consistent interface, quickly | Tailwind CSS or the team’s existing design system | A design system already in place in another technology |
| Data hosted in Switzerland or the EU | Host and region chosen for the database and files, checked in the provider’s documentation | If no requirement imposes it, region choice stays a latency and cost decision |
TypeScript
JavaScript with types checked before it runs.
When: As soon as a product has more than a few files or more than one person.
React
A library for building interfaces from components.
When: Interactive interfaces, reusable components.
Not when: A simple content site.
Next.js
A React framework with server rendering, routing and server actions.
When: Apps and SaaS that also have public pages to rank.
Not when: A pure API with no interface, or a team already productive with another framework.
PostgreSQL
A proven open-source relational database.
When: Most products with users and related data.
Supabase
Managed Postgres with authentication, file storage and row-level access rules.
When: Starting quickly without running a database server.
Not when: An infrastructure already mandated by your organisation.
Stripe
An online payment service: one-time payments, subscriptions, refunds.
When: Charging inside an app or a SaaS.
API and backend
The server, the API and what runs behind them
- REST API or server actions
- A REST API exposes URLs other programs call (a mobile app, a partner). A framework’s server actions, as in Next.js, are enough when only your own interface calls the server. A public API pays off when a client other than your site needs it.
- Validation
- Every incoming value is validated on the server against a schema (types, lengths, allowed values), even if the form already checks it: the browser is never the source of truth.
- Versioning
- An API others use does not change without warning: new fields are added without breaking old ones, breaking changes ship under a new version.
- Background jobs
- Sending emails, generating a document, syncing data: anything slow or likely to fail leaves the user’s request, in a queue or a scheduled job, with retries.
- Rate limiting
- A form, a sign-in or an API with no per-address or per-account limit invites abuse. Limit it, and log without recording sensitive data.
Database
The data model before the screens
A product is first a data model: which entities (a customer, a case, an invoice), which relations, who owns what. Write it down before the first page; it is the most expensive decision to change later.
- Choosing: a relational database such as PostgreSQL suits the vast majority of products; a document database or a no-code tool can be enough for simple, loosely related data.
- Migrations: every structural change goes through a versioned migration in the repository, applied the same way in test and in production.
- Isolation: in a multi-customer product, every row carries its owner and every query filters on it — or the database enforces it with row-level access rules.
- Backups: check they exist and how often, and run a test restore at least once. A backup that was never restored is not a backup.
Authentication
Who is signed in, and who may see what
- Authentication
- Proving who the person is: password, magic link by email, sign-in through a provider. Use a proven service or library rather than writing your own.
- Authorisation
- Deciding what this person may do, on each piece of data, on every request. This is where most data leaks happen.
- Sessions
- A secure cookie (HttpOnly, Secure, SameSite) identifying the session on the server; a limited lifetime and a sign-out that really invalidates the session.
- Roles and row-level access
- Admin, member, client: roles are checked on the server. The database’s row-level access rules (Row Level Security in Postgres) add a second barrier.
Payments
Charge, confirm, refund
- One-time payment or subscription
- A one-time payment unlocks access or a product; a subscription adds renewals, failed payments, plan changes and cancellations to handle.
- Stripe Checkout
- A payment page hosted by Stripe: you never handle card data, and common payment methods are taken care of.
- The webhook is the source of truth
- Stripe notifies your server when a payment is confirmed. That signal, verified by its signature, unlocks access — not the success page, which can be reached without paying.
- Refunds and disputes
- Decide what happens to access after a refund or a dispute, and who can trigger a refund.
Before opening payments
Integrations
Connecting your tools without fragility
- Read the API’s official documentation before promising the integration: rate limits, authentication, the data really available.
- Receive events by webhook when the service offers it, rather than polling its API — and verify every webhook’s signature.
- Plan for failure: spaced retries, and a queue of failed calls someone can replay.
- Make every operation idempotent: replaying a call or an event must not create a duplicate.
- Keep API keys on the server, in environment variables, never in browser code or in the repository.
Going live
What separates a demo from a product
- Security
- The most common web application risks are documented by OWASP (broken access control, injection, misconfiguration). Check your product against that list before launch.
- SEO
- Server-rendered public pages, unique titles and descriptions, a sitemap, honest structured data. Private pages do not need to be indexed.
- Performance
- Measure on a real phone and an average connection: sized images, little client-side JavaScript, no request waterfalls.
- Analytics
- Measure a few events that matter (sign-up, activation, payment), with no free text or personal data, and with consent where it is required.
- Transactional emails (confirmation, password reset) sent from an authenticated domain, so they do not land in spam.
- Files
- Private storage by default, types and sizes checked on the server, signed and temporary download links.
- Deployment
- A reproducible deployment from the repository, with a preview environment, environment variables separated per environment, and a way to roll back.
- Error monitoring
- Server and browser errors end up somewhere someone reads them, with no sensitive data in the logs.
- Iteration
- After launch, watch what users really do, fix what blocks them, then add — in that order.
The path
Twelve stages, from the idea to a product that runs
Every stage points to a resource that exists. The detailed path, with exercises and checks, is Build School’s.
- 01
Validate the problem
Who has this problem, how do they solve it today, and what would prove they would pay for better?
AvailablePrototype or v1?
- 02
Define the v1
One main flow, the list of what will wait, and what makes the v1 “done”.
AvailableSaaS Starter Kit (free checklist)
- 03
Choose the approach
Site builder, no-code or code; build it yourself, with help, or delegate it.
AvailableFree diagnostic: build, buy or delegate (in French)
- 04
Write the data model
Entities, relations, the owner of each piece of data.
AvailablePostgreSQL documentationPostgreSQL
- 05
Set up the environment
Git repository, editor, environment variables, a first empty deployment.
AvailableGitHub — Get startedGitHub
- 06
Build access
Authentication, sessions, and authorisation checked on the server.
AvailableOWASP ASVSOWASP
- 07
Build the main flow
From sign-in to result, end to end, before any secondary screen.
AvailableNext.js documentationVercel
- 08
Wire payments
Checkout, a signed and idempotent webhook, a tested refund.
AvailableStripe webhooksStripe
- 09
Connect integrations and emails
External services with retries, transactional emails.
AvailableBuilding a SaaS with Next.js: the order that avoids rewrites
- 10
Verify before production
Access, data, payments, errors: each point verified, not declared.
AvailableShipCheck — is your app production-ready? (in French)
- 11
Go live
Domain, authenticated emails, error monitoring, backups.
- 12
Launch and iterate
First users, simple measurements, fixes, then new features.
Frequently asked questions
How do you build a SaaS?
First validate the problem with real users, then build in order: data model and per-customer isolation, authentication, one complete main flow, a subscription confirmed by webhook, emails, and a verified production launch. The article Building a SaaS with Next.js covers each step.
How do you launch an MVP without building everything?
Cut the v1 down to a single flow that solves the main problem, and write down what will wait. Often a no-code tool or a page with a form is enough to check the problem is worth solving. See Prototype or v1?.
No-code or custom development?
No-code is excellent for validating quickly or equipping a team. Custom code pays off when the product carries business rules to test, data to control, integrations with no connector, or platform costs that grow too high. The free build, buy or delegate diagnostic (in French) helps decide.
How do you build a client portal?
The heart of a client portal is authorisation: every request checks on the server that the person may see this specific case. Add private file storage with signed links, and keep the interface simple — list, detail, actions, statuses.
How do you connect Stripe payments?
Create a Stripe Checkout session on the server, send the person to the payment page, then grant access when your server receives the signed webhook confirming the payment. Make that webhook idempotent and test a refund before launch.
How much does a web product cost?
It depends on scope, not technology: the number of roles, rules, integrations and payments. The SaaS cost calculator gives a range from your answers; for a brochure site, see how much a website costs in Switzerland.
Do I need a mobile app or a web app?
A web app that works well on a phone is enough for most first versions, and it avoids app store review. A native app pays off when hardware access, reliable notifications or an App Store presence are essential — see building an iOS app.
Sources
- The TypeScript HandbookMicrosoftChecked on 23 Oct 2026
- React — LearnMeta / ReactChecked on 23 Oct 2026
- Next.js documentationVercelChecked on 23 Oct 2026
- PostgreSQL documentationPostgreSQLChecked on 23 Oct 2026
- Supabase documentationSupabaseChecked on 23 Oct 2026
- Stripe documentationStripeChecked on 23 Oct 2026
- GitHub — Get startedGitHubChecked on 23 Oct 2026
- OWASP ASVSOWASPChecked on 23 Oct 2026
- Stripe webhooksStripeChecked on 23 Oct 2026