Application shapes

What kind of application does your business actually need?

PrimeLabs builds different shapes for different operational problems. Some are mainly internal. Some are for people who sign in from outside. Some move work through stages. Some turn documents into records. Many real applications combine more than one.

Where does the problem mainly live?

Pick the closest description. It is a starting point, not a boundary.

A Inside the business Internal business application Staff are keeping the work in spreadsheets, email, shared folders or tools that do not share a record.
B Between you and signed-in users Customer portal Customers, clients, members, suppliers or partners need their own status, files or actions.
C In what happens next Workflow automation The work moves through stages, people and systems, and the current step is not visible.
D In a file that has to be read Document workflow Incoming documents need fields, a check, a review and a recorded decision.

Many systems combine two or more. A portal can show the state of a workflow. A document review can be one stage. An internal application can contain both. AI can appear in any of them where it removes work, and the Cloudflare architecture can sit under any of them.

Need the systems you already use to participate?

That is a connecting capability, not a fifth application shape. API integrations read from a CRM, a ledger, a payment provider or another product, prepare a change, and write only when the contract allows it. Any of the four shapes can need that connection. The connection is not itself the application a person opens.

Signals that a shape fits

Internal business application

The operational process itself needs a better home.

Spreadsheets are becoming fragile
Records are duplicated
Status is unclear
Reporting is assembled by hand
Too many tools hold one job

Customer portal

External users repeatedly need secure information or an action.

The same status question arrives every week
Documents go back and forth by email
People ask to do it themselves
The record belongs to one account
The relationship is recurring

Workflow automation

The hard part is what happens next.

Approvals
Waits
Retries
Calls to another system
Exceptions
Status scattered across inboxes

Document workflow

The process begins with a file.

Staff rekey the same fields
Files need a category
Evidence has to be reviewed
A compliance record must stay with the job
Extracted values need a rule, not only a reading

The four shapes, side by side

A reading aid. Not a feature matrix, and not a claim that a build includes every cell.

How the four application shapes differ
	Internal	Portal	Workflow	Documents
Primary users	Staff	Signed-in external users	Staff, systems, sometimes a customer	Reviewers, then other systems
Core problem	The process has no shared home	People keep asking for status	Nobody can see the next step	The work arrives as a file
Typical data	Cases, owners, status	Their records and actions	The run and its history	Fields, confidence, the original
State	Visible on the record	The next thing they can do	Durable, including waits	Review, then a chosen write
Documents	Kept when they are evidence	Their own files	One stage, when a file is required	The subject of the application
Customer-facing	No	Yes	Sometimes	Only if they upload
Likely integrations	Systems the process already uses	The record behind the account	CRM, ledger, identity, APIs	The record the file belongs to
Common AI use	Summarise, classify, find a gap	Answer from permitted records	Propose a route. Do not approve	Extract and flag. Rules decide
Starting scope	One process	One relationship	One process that waits	One document type

Internal

Primary users: Staff
Core problem: The process has no shared home
Typical data: Cases, owners, status
State: Visible on the record
Documents: Kept when they are evidence
Customer-facing: No
Likely integrations: Systems the process already uses
Common AI use: Summarise, classify, find a gap
Starting scope: One process

Portal

Primary users: Signed-in external users
Core problem: People keep asking for status
Typical data: Their records and actions
State: The next thing they can do
Documents: Their own files
Customer-facing: Yes
Likely integrations: The record behind the account
Common AI use: Answer from permitted records
Starting scope: One relationship

Workflow

Primary users: Staff, systems, sometimes a customer
Core problem: Nobody can see the next step
Typical data: The run and its history
State: Durable, including waits
Documents: One stage, when a file is required
Customer-facing: Sometimes
Likely integrations: CRM, ledger, identity, APIs
Common AI use: Propose a route. Do not approve
Starting scope: One process that waits

Documents

Primary users: Reviewers, then other systems
Core problem: The work arrives as a file
Typical data: Fields, confidence, the original
State: Review, then a chosen write
Documents: The subject of the application
Customer-facing: Only if they upload
Likely integrations: The record the file belongs to
Common AI use: Extract and flag. Rules decide
Starting scope: One document type

API integrations are not a fifth column. They are how one of these shapes talks to a product that already owns the record.

Real applications rarely fit one box.

One believable path. The certificate is an example of how the shapes hand work to each other, not a client project.

A customer uploads a compliance certificate
The file enters through an account that already exists.
Customer portal
The signed-in place the file arrives, and later the place the outcome is visible.
Document workflow
Fields are extracted, checked against the job, and held where confidence or a rule says so.
Workflow automation
The run pauses for a person. A retry or a wait is part of the history.
Internal business application
Staff see the case, the evidence and who can approve it.
Customer portal, again
The approved status is shown to the account that uploaded the file. The internal queue is not.

If the record lives in a system this application does not own, that write is an API integration.

Custom software is sometimes the wrong answer

PrimeLabs will say so. A mature product you already pay for may fit the process. The job may be rare and simple enough to stay a checklist. The organisation may not yet agree what “finished” means, and software would freeze the argument. The gap may be configuration, or a connection between systems that already exist, rather than a new application. The cost of a custom build may be larger than the problem.

Those are reasons to stop, or to start smaller than the diagram above. They are part of the engineering judgement, not a softer way of saying yes.

These are shapes. The service is still an application.

The pages under this one describe common kinds of operational software. The broader service is custom web application development: users, records, permissions and a release process around whichever shape the work needs.

Where a model belongs inside that application is AI application development. Which Cloudflare services a particular shape actually needs, and which it should leave out, is Cloudflare application development. Neither of those pages replaces the choice above.

Discuss the shape