Users need to log in and see their own data
Customers, members or partners each get an account and must only ever see their own records. That is authentication, permissions and a data model, not a page template.
White label web application development for agencies.
For when the brief outgrows the website.
Client portals, dashboards and internal tools that sit behind the site your agency built. I build the application under your brand, connect it to the site and hand it over documented. Feasibility review: €490, fixed price.
Milan Danilovic, founder- White label under your brand
- Built to your designs
- Documented for handover
- Based in Serbia · European time zones
When a website becomes an application
It started as a website.
Then the client asked for a login.
Many application projects arrive disguised as website briefs. Spot one early and you can quote it properly instead of stretching a CMS until it breaks.
The client describes a process, not pages
Requests, approvals, statuses, who does what next. Once the work has states and owners, a CMS plugin starts to fight you.
Numbers have to be calculated, not just shown
Quotes, scores, availability, reports. Logic that has to be right every time belongs in tested code on a server.
Several systems feed one screen
A dashboard that combines the CRM, the shop and a spreadsheet needs a backend that owns the joining, the caching and the errors.
The plugin list keeps growing
When one job needs five plugins and custom glue between them, a small purpose-built application is usually simpler to run and safer to update.
What I build
The part of the project
that needs a backend.
- Client and customer portals with accounts and permissions
- Dashboards and reporting views, including PDF export
- Internal tools: admin panels, approval flows, back-office screens
- Quoting, booking and calculation tools
- Multi-tenant apps where each customer’s data stays separate
- The APIs and background jobs behind all of the above
Working with the existing site
Your site stays.
The app sits beside it.
An application rarely means rebuilding the site. The site keeps doing what it is good at, and the app takes the jobs a CMS was never built for.
The marketing site stays where it is.
WordPress or Webflow keeps the public pages and the content team keeps its editor. The application runs on a subdomain such as app.clientname.com or under a path, deployed and updated on its own schedule.
It looks like the same product.
I build the interface from your designs and components, so a visitor moving from the site into the portal does not feel the jump. Your agency’s design work carries straight through.
The two sides talk through APIs.
When the app needs CMS content, or the site needs data from the app, they exchange it through APIs. Neither reaches into the other’s database, so either side can change without breaking the other.
Sign-in is agreed, not improvised.
Login and account links on the site point into the app. If the client already has user accounts somewhere, we decide up front whether the app uses them or manages its own.
Stack
Common tools,
so your team can maintain it.
TypeScript from the browser to the database.
React and Next.js for the interface, Node.js or NestJS for the API, and PostgreSQL or a document database depending on the shape of the data. Shared validation schemas keep the frontend and backend in agreement about every request.
Slow work happens in the background.
Reports, imports, exports and AI processing run as background jobs with visible states, so a page never hangs waiting and a failure shows up as a failure.
Delivery and handover
Working software
at every milestone.
I lead every project and stay your single point of contact. When the scope needs more hands, I bring in developers I already work with, under my review.
- 01
Feasibility review
I review the brief, the existing site and the data, then send a written plan, risks and an estimate you can quote from.
- 02
First working slice
The first milestone is one real journey working end to end, such as “log in and see your orders”, on a staging address you can click through.
- 03
Reviewable milestones
Each milestone ends with working software on staging and a short written update. Scope changes are agreed before they are built.
- 04
Testing and acceptance
Permissions, failure states and the main journeys are tested against agreed acceptance criteria. Your nominated owner signs off each release.
- 05
Handover
Repository, deployment and admin documentation, and a walkthrough with your team. Ongoing support is a separate agreement.
Pricing
Quote the application
once the unknowns are known.
Feasibility review, €490 fixed
A written plan, risk list and estimate for the application, based on the brief, the existing site and the systems it has to work with.
Engineering pilot, from €2,900
The first working slice of the application with acceptance criteria, so you can judge the collaboration on real software. Larger builds get a fixed quote after the review.
Typical project start: 1–2 weeks after agreement, subject to availability. Prices in EUR, excluding VAT.
See all partnership pricesProof of capability
Applications I have
designed, built and run.
Most of my client applications are under NDA. These are the ones I can show: my own products, live in production, plus systems I built in employment. Each one shows the kind of application an agency brief turns into.
CultureFitr: a multi-tenant workspace with reports
Each recruitment agency works in its own data context; a request for another agency’s records returns not found. AI explanations run as background jobs with visible states, and the PDF is rendered from the same report view users see on screen.
Inside CultureFitrSignageStack: a browser dashboard driving real devices
Operators manage screens, media, playlists and working hours from a React dashboard backed by a NestJS API. The preview mounts the same renderer as the screen player, so what operators approve is what plays.
Inside SignageStackMorgenlese: accounts, progress and a public library
Server-rendered Next.js pages, sign-in, learning progress stored in PostgreSQL and learning rules that are tested on their own. It is free to read in the browser and installable on a phone.
Inside MorgenleseEmployment: new interfaces on an existing backend
In an enterprise workflow modernization I worked on, new frontend functionality ran alongside established backend services and data models, and document processing fed a human review workflow.
Selected engineering experiencePractical questions
Application questions agencies ask.
Should this be a plugin or a separate application?
If it is mostly content with a form or two, the CMS or a plugin is usually the right call, and I will tell you so. Once there are user accounts with private data, multi-step workflows or serious calculation, a separate app is easier to secure, test and change. The feasibility review is where we decide.
Can the app match the site we designed?
Yes. Send the design files or the component library and I build to them. Screens the designs do not cover yet, such as empty states and error messages, get flagged early so they are designed, not guessed.
Where is it hosted?
On accounts owned by the client or your agency, agreed before the build. I set up deployment, document it and hand over access. Hosting and third-party service costs are billed to the account owner.
How are user accounts and personal data handled?
Access rules are designed with the data model, not added at the end: every request checks who is asking and what they may see. I keep personal data to what the workflow needs and agree with you where it is stored. Privacy policies and data processing agreements stay with your client and their advisers.
Will it work on phones?
Yes. Interfaces are responsive by default, and an app can be made installable on a phone where that helps, as Morgenlese is. Native app store releases are a separate scope.
Start with the first journey
What should your client’s
users be able to do?
Describe who logs in, what they need to see or do, and which systems hold the data today. A link to the existing site helps. I’ll come back on fit, feasibility and a useful first scope.
Describe the application