Inside the Next Generation of PentaPaper: Building a Modular Business Platform

Most businesses do not run on one workflow.

A new contact becomes a lead. A lead turns into an offer. An accepted offer becomes a project. The project creates tasks, documents, time entries, expenses and invoices. Somewhere in between, there are contracts, notes, files, follow-ups, inventory, tax obligations and years of accumulated relationship history.

Yet business software still tends to divide all of this into separate worlds.

The CRM knows the customer, but not necessarily the project. The project manager knows the work, but not the invoice. The invoicing system knows the money, but often very little about what actually produced it. Documents live somewhere else again. Reporting then tries to reconstruct the bigger picture from disconnected pieces.

PentaPaper started from a simple question:

What if those things belonged to the same system in the first place?

Over the past months, we have been bringing the next generation of PentaPaper into focus — not only with a new visual language, but with a much clearer product architecture around that idea.

And in November 2026, we plan to open that next iteration to a broader public beta.

One business, one connected model

PentaPaper is not meant to be a pile of unrelated modules that happen to share a navigation bar.

The more important idea sits underneath.

A customer should not exist independently in your CRM, invoicing tool, project manager and file store.

It should be the same customer everywhere.

An organization in PentaPaper can be connected to its people, projects, offers, invoices, contracts, tasks, files, expenses, opportunities and activity history.

A project can connect the client, milestones, team members, working time, documents, billing, files and operational activity.

An invoice can know which customer and project it belongs to. A contract can be related to the same entities. A follow-up can sit inside the same relationship history. Statistics can then analyze the connections instead of trying to reconstruct them afterwards.

That leads to one of the principles behind PentaPaper:

Generic where it should be. Specific where it matters.

Contacts, money, documents, projects, tasks and files are common business primitives.

A photo shoot, a construction site visit, a hotel guest workflow or an agency campaign is not.

PentaPaper is designed to keep the common foundation shared while allowing specialized workflows to grow on top of it.

More than CRM, invoicing or project management

It is tempting to describe PentaPaper by listing software categories.

And technically, a lot of them apply.

PentaPaper already spans areas such as:

CRM and contacts

People, organizations, customers, leads, relationship history, follow-ups, opportunities and segmentation all live in the same contact model.

The CRM is not a separate sales island. Commercial activity can connect directly to the projects, documents and work that follow.

Projects and productivity

Projects combine milestones, tasks, team members, files, notes, time tracking, financial context and activity history.

The Organizer layer adds internal notes, to-do lists, documents, quick capture and productivity workflows around that operational core.

Business documents

Offers, orders, invoices, reminders, contracts and credits share one document foundation.

That also gives us a path toward custom document types later — without creating a completely separate subsystem for every variation a business might need.

Inventory and operations

Expenses, products, stock, suppliers and physical assets are becoming part of the same platform.

The current foundation can grow further into purchasing, multiple inventory locations, warehouse workflows, receiving, transfers and other physical operations.

Finance, VAT and statistics

Because financial data does not live in isolation, PentaPaper can connect revenue, expenses, invoices, taxes, projects, customers and working time.

The statistics layer can then answer questions that become much harder when those data points are split across five different products.

This means PentaPaper overlaps with categories such as CRM, project management software, invoicing platforms and ERP systems.

But we are deliberately not trying to recreate the traditional monolithic ERP.

The goal is a more modular business platform.

A new interface for a much more coherent product

The new generation of PentaPaper also needed to feel like one system.

Over time, mature software accumulates interfaces from different eras. Features are added. Workflows evolve. Individual screens solve their problems, but the visual language gradually drifts apart.

This iteration brings those surfaces back together.

PentaPaper now uses a calmer visual system built around jade and mineral tones, cool neutral surfaces, stronger information hierarchy and proper light and dark themes.

The dashboards have become more contextual.

Instead of simply showing rows of entities, they answer questions.

The project view brings progress, milestones, working time, billing, files, tasks, team members and the customer together.

The documents dashboard shows the lifecycle across offers, orders, invoices, reminders, contracts and credits.

The contacts dashboard combines relationship health, commercial context, follow-ups and CRM activity.

The inventory dashboard connects products, purchasing, suppliers, expenses and physical stock.

And the main dashboard is becoming less of a static collection of numbers and more of an operational front door: what needs attention, what is happening today, what you were recently working on, and where the business is moving.

We still like business software that acknowledges the human using it.

That is why the main workspace can sit over changing seasonal imagery while the actual information stays calm and readable above it. The software does not have to become sterile just because it deals with invoices and tasks.

Specialization without rebuilding the business underneath

The clearest example of where we want to take this architecture is PentaPaper Photo.

A photography business still needs ordinary business infrastructure.

It has customers. Projects. Offers. Contracts. Invoices. Expenses. Files. Tasks. Working time.

But photography introduces its own domain:

• photo shoots
• models and other participants
• locations
• moodboards
• setups
• image selections
• retouching states
• deliverables

Building a separate photography CRM would mean duplicating a huge amount of infrastructure that already exists.

Instead, PentaPaper Photo can add the concepts that are actually specific to photography while reusing everything underneath.

A shoot can belong to the same customer that appears in CRM.

It can sit inside the same project system.

Its final work can lead into the same invoicing and document workflows.

Its expenses can flow into the same financial model.

Its locations become proper managed entities rather than text fields buried in a shoot description.

PentaPaper Photo is not a separate CRM for photographers. It is a photography workflow built on top of the same business platform.

That distinction matters.

And it is the pattern we want to repeat.

Agencies, consultants, service businesses, creative studios, trades and other industries often share a surprising amount of common infrastructure. The valuable part is identifying where that common model ends and the genuinely specialized workflow begins.

The architecture behind it

PentaPaper is built on our own software stack at Neoground.

The backend is based on our PHP framework Charm and the shared Mainframe application foundation we use across our ecosystem.

The philosophy is deliberately pragmatic.

We want modularity without turning every feature into its own distributed system.

Shared services such as authentication, configuration, routing, storage, notifications and application infrastructure can be reused throughout the platform. Modules add functionality and can register their own business capabilities while still working inside the same application model.

For richer interfaces, we increasingly use lightweight Preact components on top of JSON APIs.

We intentionally keep those components simple: small class-based views, straightforward state, and API structures that correspond closely to the underlying business data.

That means the interface can evolve without forcing us to rebuild the entire application around a heavyweight frontend framework.

The technology choices themselves are not the most important part.

The leverage comes from not rebuilding the same substrate every time we create a new product or vertical.

A new extension should not need its own authentication system, contact database, notification infrastructure, invoice engine, file layer and reporting foundation before we can work on the actual problem it is supposed to solve.

That shared foundation is one of the reasons we see PentaPaper as a platform rather than simply another business application.

Connected data makes better statistics possible

One of the areas where the platform approach becomes particularly visible is reporting.

If projects, customers, offers, invoices, working time, expenses and tasks all belong to the same model, statistics can become much more useful.

Instead of only asking:

“How much revenue did we make?”

we can eventually ask:

• Which project types produce the strongest margins?
• How much working time goes into a customer before the first invoice?
• Which leads become offers, projects and recurring customers?
• How does customer lifetime value relate to support and delivery effort?
• Which projects consistently overrun their estimates?
• How quickly does each customer pay?
• How concentrated is revenue across the customer base?
• How much internal time are we investing compared with billable work?
• Which suppliers or expense categories affect project profitability?
• Which relationships are becoming commercially important — or quietly going cold?

That same connected model also creates a much stronger foundation for future automation and AI than a collection of isolated databases and documents.

AI becomes much more interesting when it can work with actual structured business context rather than another folder full of PDFs.

Why not just connect five specialized SaaS products?

There are excellent specialized tools in almost every software category.

We use specialized software ourselves where it makes sense.

The problem is not specialization.

The problem is fragmentation.

Every additional system potentially introduces another copy of the customer database, another permission model, another API integration, another subscription, another reporting silo and another place where context disappears.

Eventually the business spends surprising amounts of effort keeping software synchronized with itself.

PentaPaper is not based on the assumption that one application should replace every specialized tool on Earth.

The idea is more practical:

Build the common business foundation once, and specialize from there where shared context creates real value.

Some workflows will remain better served by dedicated external tools. APIs and integrations remain important.

But the central business model should not need to be reconstructed from scratch every time another capability is added.

One platform, many possible businesses

This is also where the longer-term potential becomes interesting.

A modular architecture gives us two directions at once.

PentaPaper can continue becoming a stronger horizontal business platform: CRM, projects, documents, productivity, operations, reporting and financial workflows.

At the same time, extensions can go deeper into particular industries.

The shared core makes those vertical products cheaper to build, easier to maintain and more useful because they do not start from an empty database.

And each additional module strengthens the platform underneath.

That creates a very different development path from building a collection of standalone SaaS products.

The core gets built once.

The interesting parts can then branch out.

The public beta is coming in November

We are currently preparing this next generation of PentaPaper for a broader public beta in November 2026.

The goal of that beta is not to claim that every conceivable business workflow is finished.

It is to make the common platform solid, coherent and genuinely useful — and then expand from that foundation.

We are particularly interested in early users who currently spread their work across several disconnected tools and would like to experiment with a more integrated approach.

That includes:

• agencies
• consultants
• freelancers
• creative studios
• photographers
• technical service companies
• small and growing teams
• businesses with workflows that do not fit neatly into one generic SaaS category

Early users will also help us understand which extensions and workflows deserve the most attention next.

Join the PentaPaper beta →

Building the business platform we wanted ourselves

PentaPaper has existed in different forms for a long time.

That history matters.

A lot of the underlying functionality did not begin as a checklist assembled for a launch page. It grew out of actually needing contacts, invoices, projects, tasks, inventory, money, marketing tools and other infrastructure ourselves.

The next iteration is about turning that accumulated foundation into a much more deliberate product.

A coherent interface.

A clearer architecture.

A stronger extension model.

And a platform that can grow without every new workflow creating another isolated island of business data.

The interesting part of PentaPaper is not that it can manage an invoice, a project or a contact.

Plenty of software can do each of those individually.

The interesting part is what becomes possible when customers, projects, documents, money, work and specialized workflows all understand how they relate to each other.

That is the platform we are building.

One platform for the business you actually run.