Portal development.

A portal is a website that knows who is looking at it

On a regular website every visitor sees the same thing: the same pages, the same copy, the same price list. A portal begins where that stops being enough. After signing in, each person gets their own view: a client sees the status of their case and the documents still expected from them, a collaborator sees their tasks, an editor sees the publishing tools, an administrator sees everything. Those three ingredients, a login, roles and content per user, are the line between a website and a portal, and they are why a portal is planned differently from everything else we build.

A website is drawn page by page; a portal is drawn role by role. The first question on a portal project is not which pages exist, but who signs in and what they are allowed to see. So before any design work we write a list of roles, and next to each one what that person sees after signing in, what they can change and what they get notified about. Once that list is settled, the screens practically read themselves out of it; when it is skipped, the portal gets reworked after launch, when changes are most expensive.

Technically, a portal with a login is a web application, so the wider picture of how such software is built and maintained is on our custom software page. And if you are still weighing whether you need a portal, a mobile app or simply a well-built website, that is a conversation we have before any quote. Here we stay with what is purely portal work: statuses a client reads, membership content behind a login and an editorial team that publishes.

Client portal: clients see for themselves how far things have got

The most common reason for a portal looks like this: work for a client runs for weeks, consists of steps and documents, and in the meantime the client calls and writes to ask how far things have got. Every call interrupts the work, and every "almost there" answer spends trust. A client portal shuts that traffic down: the client signs in and sees the status of their case, what is with you for review and what is expected from them, at three in the morning if they like, without a single email.

That is how Certiwa Portal works, a portal we built for Swedish ISO consultants from Malmö. ISO certification means dozens of documents across several standards at once, so on the portal every document carries a status: approved, under review, needs additions, expiring soon. The overview says what comes next and what is with the consultant, progress toward the scheduled audit is tracked per standard, and the whole portal runs in Swedish, in the same visual identity as the presentation website we had built for the same client earlier.

The part that matters most to you: that portal is publicly available as a demo, with fictional data. Instead of taking our word for how a client portal looks from the inside, walk through it yourself before you sign anything.

From that project we also carry a rule that saves money: keep the number of statuses small. A portal is worth exactly as much as its data is fresh, and a status is changed by a busy person in the middle of real work. Four statuses that actually change are worth more than fifteen that sit still, so every portal ships with an email notification when a status changes, so the client does not sign in every day only to confirm that nothing has happened.

Member and internal portals: what should not sit in public

The second pattern has no case in progress, but people who belong to an organisation: members of a federation or association, chamber members, franchise partners, your own employees. What is emailed to fifty addresses today, with nobody remembering a month later which attachment it was in, sits in one place on the portal, behind a login: decisions and minutes, forms and documents, announcements, an internal directory, membership fee records. A member signs in and finds it, instead of digging through an inbox or calling the office.

Three questions get settled here before any building starts; they look small and carry the whole portal. First, who opens the accounts: one by one from the admin panel or by importing an existing member list, and who switches access off when someone leaves. Second, what stays public: the membership page, news and contact must remain visible to everyone, because that is the only part Google indexes and the way new members find you; the most common mistake member portals make is locking everything, so from the outside they look like a blank wall. Third, who publishes: announcements are entered by a secretary or office staff, not a developer, so entry has to be simple and workable from a phone.

An internal portal for employees is the same mechanics with a different vocabulary: procedures and internal documents instead of membership fees, and leaving the company instead of leaving the membership, after which access is switched off with one click, not forgotten.

Information portal: structure and editorial tools instead of a login

The third type of portal often has no login at all, or only the editors have one. An information portal lives off publishing: sections, news, an events calendar, results, archives by season, documents to download. What you are really buying is not the front page but a structure that knows in advance where everything goes, and a tool through which content is published by people whose main job is something else.

That is how the website of the Aeronautical Union of Serbia is set up: a national federation with disciplines from gliding and parachuting to aeromodelling and ballooning, clubs across the country, a competition calendar, results by season, news and documents, all in Cyrillic. Every discipline has its place, results stack into an archive by season instead of burying the front page, and the federation updates the content itself, without us in the loop. Members and clubs now find information on the site instead of in email threads, and the federation has a tidy public face for its audience and sponsors.

With an information portal, two decisions are expensive if made late. The first is the archive: results, bulletins and old news need their place before they pile up, because structure is hard to change underneath a thousand published items. The second is the naming of sections: sections are named after what the reader is looking for, not after your internal organisation; the reader does not care which committee issued a document, only where the forms live.

Portal development cost: three scopes, three figures

A portal with a login is a web application in scope, so pricing starts from €2,000: login, one main record set, statuses and administration. Client and member portals with several roles, notifications and connections to the software you already use start from €3,000. An information portal without a login is closer in scope to a corporate website, from €800, because the work goes into structure and publishing tools rather than accounts. Indicative prices per project type are on the pricing page, and the scope of a portal is pinned down from the list of roles and the inventory of content.

The scope, and with it the figure, is moved by the same few things every time:

• Number of roles. Client plus administrator is one job; client, collaborator, editor and administrator is another, because every role brings its own screens and its own permissions.
• Notifications. An email when a status changes is standard, while expiry reminders and weekly digests are an add-on agreed up front.
• Content that moves in. An empty section and a ten-season results archive are not the same job, so we ask for an inventory of existing content before the quote, not after it.
• Integrations. If statuses or membership already live in some software, the portal connects to it, so data is never entered twice.

Deadlines on portal projects rarely slip on the technology. They slip on two decisions on your side: the list of roles and the inventory of content. That is why we ask for both before we start, and then treat the date in the quote as a date. The fastest route to a figure: describe through the contact form who would sign in to the portal and what they need to see, and a concrete proposal arrives within 24 hours.