SaaS client portal

If your clients get their reports by email, their data sits in several spreadsheets and you check order status in your notes, every “could you send me that invoice again” costs you a few minutes. Over a month those minutes turn into hours, and the client still feels they have to chase you for everything.

A SaaS client portal gathers all of that in one place. The client logs in, sees their data, invoices and ticket status, pays their subscription and downloads documents, and you see the same in your dashboard, for every client at once. We build these client portals, CRMs, order management systems and reporting platforms as part of our web app offer.

Before we draw the first screen, we map the process you handle by hand today: who asks for what, who answers, where the data comes from and where it gets stuck. This happens through strategy and direction, because only with that map can we see which screens are needed at launch and which can wait for a second stage.

The scope depends on what your clients ask you about today, and hardly anyone needs every module at once. Each feature added at the start makes the build longer and the price higher, so we usually begin with two or three and add more when clients actually ask for them, without rewriting what already works. Typical modules are:

• KPI dashboard

  revenue, active users, churn and MRR on one screen

• CRM and pipeline

  clients, leads and sales opportunities with full contact history

• Client portal

  clients log in and see their orders, documents, invoices and ticket status

• Reporting system

  automated PDF reports, CSV exports, charts and filters

• Team management

  roles and permissions, task assignment, progress tracking

• Notifications

  email, push and in-app, so nobody misses an important change

It takes one client seeing someone else’s invoice in the portal to lose their trust. So we design permissions at the very start, together with the process map. Every role, from administrator through staff to client, sees only what it should, and in the Postgres database we also secure data at row level (RLS). If someone ever found a gap in the interface, the database still would not hand over another client’s data.

Clients log in with email, a Google account or a magic link, with no extra password to remember. We build the portal through our apps and PWA service on Next.js and React, with NextAuth, a Neon Postgres database and Drizzle ORM. It works the same on a phone as on a desktop, and as a PWA it installs straight from the browser and sends push notifications.

Before we write code, a clickable prototype comes out of our design that sells service. On it we check with you and your clients whether the paths are clear: where to find an invoice, how to report a problem, how to change plans. A fix on the prototype takes minutes; the same fix in a finished app takes days.

If you sell access on a subscription, billing belongs in the portal from day one. We integrate Stripe Billing: monthly and annual plans, free trials, per-plan limits, automatic invoicing, upgrades and downgrades, and a portal where clients change their plan or card themselves. You see the state of every subscription in your own dashboard.

We set billing up around your pricing model: per user, per feature bundle or a flat monthly fee. The app enforces the limits, so a client who hits the ceiling of a cheaper plan sees an offer to upgrade instead of an error message. When you change your pricing a year from now, the portal will not need rebuilding.

Every event in Stripe reaches the portal through a webhook, so nobody on your team checks by hand who has paid or sends out reminders. Payments, email and connections to outside systems are built through our integrations and automation service. The portal responds on its own:

• After a new payment, access switches on right away and the invoice goes to the client automatically

• After a failed charge, the client gets a notification and enters a new card themselves

• After a cancellation, access ends on the plan’s terms and the change shows in the dashboard at once

• After a refund, payment status and documents update with no manual work

At the end of every stage you get something you can see and click through. The first weeks go to discovery and the prototype, then the code is written in weekly sprints, and you review each change on a separate preview URL before it reaches your clients. Kacper Baranowski runs the project personally from the first call to launch, so you explain your process once, to one person.

The dashboard layout follows the decisions you make from it. If you check MRR and churn every Monday, those two numbers sit at the top of the screen. If clients mostly ask about order status, status is the first thing they see after logging in. The rest of the data is within reach and does not crowd out what you look at most.

• Discovery

  the process you handle by hand today, the roles, the data and the systems to connect

• Prototype

  clickable client and team paths, tested before the first line of code

• Build

  Next.js, React and Postgres in weekly sprints, deployed with CI/CD on Vercel

• Launch

  data migration from spreadsheets, client invitations, team training and monitoring in Sentry

A simple client portal costs from PLN 20,000 net. A full platform with CRM, billing, analytics and multiple roles is PLN 80,000 net and up. A simple portal takes 4–6 weeks, an extended platform 8–16 weeks. You get a free first quote with a written scope and schedule within 48 hours of the call. We confirm the final figure after discovery, because two portals with the same name can differ in scope several times over, and the scope goes on paper before you sign a contract. The other packages and extras with their prices are in our pricing.

Coding starts once the scope and prototype are approved. Projects of this size are billed by stage, with a VAT invoice for each stage, so you do not pay the whole amount up front. Five things move the price most:

• Number of roles, because client, staff and administrator are three different sets of screens and permissions

• The set of modules

  the portal, CRM, reports and billing can ship together or in stages

• Integrations, because each connection to a CRM, ERP or invoicing tool is its own piece of work

• Data migration, if the history in your spreadsheets needs cleaning up and mapping to portal fields first

• Automation, such as scheduled PDF reports and push notifications, which adds server-side logic

Already have a CRM or ERP and no wish to retype data from one tool into another? We connect the portal via API or webhooks to Pipedrive, HubSpot, Salesforce or your own ERP, and the data syncs on its own. If one of your systems has no API, you will hear about it before the quote, along with a proposed workaround.

After launch the portal keeps changing, because clients start using it differently than we assumed and ask for more. Bugs caused by our code are fixed free of charge for 30 days from acceptance, and after that you can order ongoing care through support and growth: weekly sprints with new features, fixes, updates and error monitoring in Sentry. The code, database and accounts belong to you, so you can hand development over to your own team, with documentation, at any time.

Still testing whether clients will pay for your product? Start with an MVP for a startup and grow it into a full portal once the idea is validated. If the portal has a public side, such as a pricing and sign-up page, we take care of its visibility on Google through SEO and analytics. And if you want to know what your portal would cost, describe in two sentences in the contact form what you do by hand today and who keeps asking for it. We reply personally by the end of the next working day and set up a call, after which you get your quote.