PrimeLabs · Perth
Custom web applications built around the way the work actually happens.
PrimeLabs designs and builds operational software, customer and member portals, and product applications. The aim is a system people finish a job in, shipped in weeks and then changed as the job changes.
Example interface. Not a client project.
Harbour yard · 28 Sep 2026 · 42 staff
Work in flight
Three roles: yard, office, finance
| Job | State | Waiting | Owner |
|---|---|---|---|
| Northside delivery dockets | Waiting on attachment | 2 days | Yard |
| Member card reprint | Ready to approve | 4 h | Office |
| Supplier credit INV-4702 | In review | 6 h | Finance |
| Weekend roster exception | Completed | 18 min | Operations |
Three jobs are waiting on the same missing docket.
The signed delivery docket is absent on the Northside run and on two related credits. The queue can filter to that attachment. This note does not reassign the jobs.
Approval · member card reprint
Office can release the reprint
Waiting on a person. Nothing has been written.
Week of 22 Sep 2026
What the queue produced
Figures are counts of jobs in this example, not a forecast.
A website, an application, and a product are not the same job.
The words get used interchangeably. The build is different, and so is the thing that has to keep working next year.
- Website
- Pages that explain an organisation. The content changes. The behaviour usually does not. PrimeLabs is not a brochure studio. Sister brand PrimeSites is the web business in the PrimeHQ family.
- Web application
- Software in the browser. People sign in, create records, move work along, and see a result that depends on who they are. The interface is part of the system, not a skin on top of one.
- Internal application
- The same idea, aimed at staff. A queue, a roster, a finance check, a store of documents. It replaces the spreadsheet and the inbox thread that were doing that job badly.
- SaaS product
- An application used by more than one organisation. Tenant data stays apart, and a change for one customer must not leak into another. That separation is a design decision, not a setting added at the end.
The brief is usually a process, not a feature list.
A typical starting point is work that already happens, just not in one place. Orders live in email. Status lives in a spreadsheet. The customer asks for an update because nothing else will tell them. Two people can update the same row and neither notice.
A custom web application is justified when that friction is expensive: delayed jobs, repeated typing, a report that never matches the source, or a new staff member who cannot see how a job is supposed to move. It is a poor fit when the organisation actually needs a published site, a packaged finance system, or a one-off document.
PrimeLabs works from Perth with organisations in Australia and elsewhere. Location matters for conversation and time zone. It does not limit the application to a single city, because the software is reached over the web.
What gets built
The homepage lists the shapes in more detail. These are the ones that come up most often as a first release.
Operational systems
A queue of jobs, an owner, a state, and a record of what changed. The example on this page is that kind of tool.
Portals
A customer or member sees their documents, requests and status without sending an email to ask.
Workflow and approvals
A known sequence, with a person at the step that should not run unattended.
Dashboards that belong to the work
Counts taken from the same records as the queue, so the chart and the job list cannot drift apart.
Integrations
A boundary to a finance system, a CRM, or another PrimeHQ product. The application stays the place the process lives.
Multi-role products
Staff, customers and administrators see different actions on the same underlying records.
The wider set of application types is on the homepage.
A small release, then the next one
Sit with the job
Who does it, what “finished” means, and which rule cannot be bent. Writing that down comes before generating screens.
Cut a slice someone can use
One path through the real work, including an awkward case. A clickable picture of a dashboard is not the slice.
Ship the unglamorous edge
Permissions, failure, an empty state, and a way to see what happened. A person approves the release.
Change it from evidence
The next version comes from how the first one was actually used, not from a second workshop that starts again.
Frame, build, operate, evolve is the short form of that loop.
The application is the product. The platform is a choice.
Most of these systems run as a Cloudflare Worker in front of a small set of data services: relational records, files, a queue, sometimes a long-running approval. The set is chosen for the job. A portal that stores PDFs needs object storage. A portal that only shows a status does not need a vector index.
That choice is written up on the Cloudflare application development page, including where each service is a poor fit. AI features, when they belong inside the product, are a separate decision from using AI to draft the code. That split is the subject of AI application development.
When to commission one, and when not to
Worth building
- The same job is done every week by several people, and the handoff is the fragile part.
- Customers or members need a truthful status without calling the office.
- The organisation will still want to change the process after the first release.
- More than one role must see the same record with different powers.
Usually the wrong tool
- The need is a public website, a campaign, or a page that does not keep state.
- A well-fitted packaged system already does the job, and the gap is configuration.
- The process is not understood yet. Software will freeze a guess.
- The only outcome requested is a model that “runs the business” without an owner.
Security is part of the application, not a layer added later
Sign-in, role checks and row-level limits live in the Worker that handles the request. A document link is issued only after that check. Secrets stay in the platform, not in the browser and not in the repository. Releases are staged, and a person decides when a change faces users.
Edge TLS and platform controls sit in front of that code. They do not replace it. An application that shows one organisation’s invoices to another has failed regardless of how the traffic arrived.
How an engagement starts
An email is enough. Useful contents are the people who use the process, what a finished job looks like, the systems that must stay, and anything the new application must not do. A proposal then names the first slice, not a twelve-month feature inventory.
There is no account on this website and no form. The conversation continues from the contact page.
Related
Questions that usually come up
Do you only build on Cloudflare?
It is the default platform, because it removes a server fleet and keeps the application close to its data services. A requirement that cannot be met there is discussed before the architecture is forced.
Can the first version be small?
Yes. The first version should be small enough to use, and complete enough that the awkward case is not left in a spreadsheet beside it.
Will you take over an existing application?
Sometimes. It depends on whether the current system can be understood, tested and changed safely. A rewrite is not the automatic answer.