Admin dashboards and back offices
The screen your team lives in: users, orders, invoices, revenue, roles and activity logs. We built the React admin panel behind Bright Future and the operations dashboard in Cargonio, both used every working day.
All services
Service · Web Applications
Web apps that load fast and stay easy to run
We build the web side of a product properly: public pages that get found and load quickly, customer portals people sign into every day, and the admin dashboard your team actually runs the business from. Laravel and React underneath, Next.js or hand-written HTML where weight matters.
Server-renderedFirst paint is HTML, not a loading spinner
Crawlable day 1Metadata, sitemaps and structured data written during the build
Every buildShips with an admin dashboard your staff run themselves
Keyboard-firstFocus states, labels and contrast checked before release
Overview
One team for the API, the dashboard and the public site
A web app is rarely one thing. There is usually a public side that has to be found on Google and open on a poor connection, a logged-in side where customers do real work, and an internal dashboard where your staff keep the whole thing moving. We build all three, plus the API sitting underneath them, so the same people are responsible from the database to the button.
That matters because the awkward problems live between layers — a report that disagrees with the invoice, a filter that crawls once the table gets large, a page that renders fine on your laptop and blank for a user in another timezone. When one team owns the API and the screens, those get fixed rather than argued about. We have done this on Bright Future's admin panel in Kuwait, where staff manage enrolments, revenue and video content daily, and on Cargonio, the freight ERP we own and sell ourselves.
- Fast by defaultServer-rendered HTML, small payloads, honest Lighthouse scores
- Dashboards built for daily useFilters, exports, permissions, audit trails
- SEO handled during the buildClean URLs, metadata, sitemaps, structured data
- A codebase you ownHanded over with docs and deploy notes
What's included
What you get with Web Applications.
Customer portals and logged-in areas
Accounts, subscriptions, billing history, document downloads and support requests. Role and permission handling with spatie packages, JWT or session auth, and sensible rate limits on anything public.
Marketing sites that rank
Static or server-rendered pages with clean URLs, proper metadata, sitemaps and structured data. Next.js where the content is dynamic, hand-coded HTML with Tailwind and Alpine where a framework would only add weight.
Reporting, exports and documents
Filterable reports, CSV exports, and PDFs generated with dompdf — invoices, statements, certificates and statutory forms. Cargonio ships over a hundred reports built on this pattern.
Payments and integrations
Stripe for USD, MyFatoorah for Kuwait, Bunny CDN for protected HLS video, plus government tax APIs like PRA and FBR e-IMS. We deal with webhooks, retries and reconciliation, not just the checkout button.
Multi-tenant SaaS
Separate data per organisation, per-tenant branding, plans and user limits, with one deployment to maintain. We solved this on our own product before offering it as a service.
How we work
From first call to live.
01
Scope and wireframes
We start with the screens, not the schema. A short discovery pass turns your requirements into wireframes and a written scope, so you can see what you are buying before anyone writes code.
02
Data model and API first
The database and API get built and reviewed early, because that is the part which is expensive to change later. A staging environment goes up as soon as there is something worth looking at.
03
Build in visible slices
We ship one module at a time, tested and on staging, rather than disappearing for three months. Our two QA engineers go through each slice on real browsers and devices before it reaches you.
04
Launch, hand over, support
Deployment to your own AWS or DigitalOcean account, Docker where it earns its place, then documentation, admin training and the repository transferred to you. We stay close while the first real users arrive.
Tools we use
The stack behind the work.
LaravelPHPReactTypeScriptNext.jsNode.jsTailwind CSSAlpine.jsMySQLAWSDigitalOceanDockerStripedompdf
Questions
Things clients ask us.
How fast will it actually be, and how do you prove it?
We agree a performance budget at scoping and test against it on a throttled mid-range Android over 4G, because that is what most of your users hold — not a laptop on office fibre. Public pages are server-rendered, and once real traffic arrives we watch Largest Contentful Paint and Interaction to Next Paint in Search Console rather than relying on lab scores alone. A logged-in dashboard with a forty-column table will never measure like a marketing page, so each gets its own target and we say which is which. The usual thing that undoes it later is third-party scripts: every chat widget and ad pixel added after launch spends some of what we optimised for.
Can our team edit the content without calling you?
Yes, and we plan for it from the start rather than bolting a CMS on afterwards. Marketing pages, pricing tables, FAQs and blog posts go behind an editor your staff can use, with the layout constrained so nobody can accidentally break the design. What we deliberately do not make editable is anything structural — page templates, checkout flows, permission rules — because those need testing before they change. If ranking well matters to you, our SEO work is a separate conversation and its own page.
Where does it get hosted, and who pays for that?
On your own AWS or DigitalOcean account, billed directly to you, so nothing sits behind our card and you are never locked out of your own servers. A small Laravel or Next.js app usually runs to tens of dollars a month; what pushes the bill up is video, file storage and transactional email rather than the application itself. We set up the servers, SSL and backups and hand you the keys — if your procurement is slow we can host under ours temporarily and transfer it, though we would rather not leave it that way for long. Ongoing monitoring, patching and upgrades are optional and priced separately from the build.
Which browsers and devices will it work on?
Current Chrome, Safari, Firefox and Edge on desktop, plus Safari on iOS and Chrome on Android, with layouts built up from the small screen rather than squeezed down to it. QA runs each release on real handsets, not a browser window dragged narrow — emulators hide keyboard behaviour, scroll quirks and how a dense table feels under a thumb. Anything older is a conversation, not an assumption: Internet Explorer, ageing Android WebViews and locked-down corporate browsers can be supported, but they change how the CSS and JavaScript are written, so tell us at scoping instead of during testing.
Should we redesign what we have or rebuild it?
It depends on whether the problem is the surface or the foundation. If the content model still matches how you work and the code is maintainable, a redesign is the cheaper answer and it keeps the search history you have already earned. Rebuild when the platform is out of support, when the CMS fights every change you ask for, or when the performance problems are structural — a new stylesheet will not fix any of those. The middle path suits more clients than expect it: keep the current site running and replace it section by section, so you are never staking everything on one launch day.
More from us
Other services.
Send us a link and a login
Point us at the site or dashboard you run today — or a rough sketch, if it does not exist yet. You will get back an honest read on its speed and search setup, what we would keep, what we would rebuild, and a first phase small enough to customise and sign off inside a week.