Why Business Software Slows Down as Your Business Grows
Most business software is fast on the day you sign up. The question is what happens three years later.
You start with a few hundred customers. Then come the jobs, the estimates, the invoices, the photos, the notes from every phone call. One day the customer list takes a few seconds to open. The import that used to work now wants the file split into pieces. Someone in the field opens the app in a basement with no signal and gets a spinner instead of the job they were about to finish.
Nothing broke. The business simply got bigger, and the software was built in a way that made every screen pay for that growth.
This post is about why that happens, and about the choices we are making in Phoundri so that it doesn't. If you want the full technical version, with sources, it is in our white paper, Beyond the Database.
The hidden cost of "load everything"
A surprising amount of software slows down for one reason: to show you a little, it handles a lot.
A table loads every row before it draws the first fifty. A calendar downloads every appointment ever booked to show this week. Editing one record means synchronizing the whole table it lives in. Importing a spreadsheet means holding the entire file in memory at once.
Each of these works fine when the data is small. Each one ties the cost of a single action to the size of everything you have ever stored. That is the real problem, and it is why adding a faster server rarely fixes it.
The principle we design around is simple: the amount of data a business owns should not decide how much data its software has to process for any one task. Showing fifty records should cost about the same whether you have five thousand or five million.
Fast should mean fast to you
There are two kinds of speed. One is how quickly a database answers a query. The other is how quickly you can get on with your work. We care most about the second, which we call instant perceived loading.
In practice it means a few things. Information already on your device should appear without waiting for the network. A table should draw only the rows you can see, which Phoundri's table grid already does. New information should arrive in the background rather than blocking the screen.
It does not mean every operation is instant. A first-time download, a large search, or a complex report still takes real work and a real connection. The goal is narrower and more useful: routine work should not get slower just because your history got longer. And we intend to measure that with performance budgets, not assume it.
Working when the internet doesn't
Plenty of work happens where the connection is unreliable: job sites, warehouses, trucks, rural offices. We think losing your signal should not mean losing your work.
Today, in Phoundri, a table you have already opened on a device stays available and editable offline. Your changes are kept on the device and sent when you reconnect. If the server cannot accept a change, for example because someone removed a field while you were away, your work is kept and shown to you rather than quietly thrown away.
There are honest limits. Offline means the information already on your device. Something you have never opened cannot be fetched without a connection. Browsers can also clear stored data under some conditions, so the copy on your device is a working copy, never the only one. And because a device that is offline cannot hear about changes in real time, an Organization can set how long a device may keep its data for offline work, and a device clears that data once it learns someone's access was removed. A dropped connection, by itself, is never treated as losing access.
Your own database, not a shared one
Many applications keep every customer's records in one large shared database and separate them with filters. That can be done securely, but it means a single mistake in a query is all that stands between your data and someone else's.
Phoundri takes a stricter approach: each Organization's records live in a database that belongs to that Organization alone. A database that once held one customer's data is never handed to another, and the system refuses to open a database when it cannot confirm who owns it.
We want to be precise about what that does and doesn't cover. Some services are shared, such as sign-in, account records, and file storage, where each Organization's files sit under its own storage path. Isolation is one layer of security, not a replacement for authentication, permissions, and careful engineering.
When one database is not enough
Each Cloudflare D1 database, which Phoundri uses, can hold up to 10 GB. That is a lot of business records, but it is a ceiling, and it cannot be raised.
So our longer-term direction is to let one Organization's data spread across several of its own databases while still feeling like one connected system. That technique is called sharding, and we want to be clear that it is a plan, not a feature you can use today.
Sharding is not magic. It adds room and lets work happen in parallel, but it does not make a single search faster, and anything that touches several databases at once needs extra care because those databases cannot share one transaction. That is why we are building toward it in steps, starting with the parts that help everyone now.
Imports that don't need to be split
Moving years of records out of spreadsheets or old software should not require chopping files into pieces.
Phoundri's imports already run as durable jobs. An interrupted import can be continued, and submitting the same import twice does not create duplicate records. Today the file is read in full in your browser, with limits of 50,000 rows per file and 250,000 rows per import by default. The next step is a streaming importer that works through a file in bounded pieces, so larger files no longer depend on how much fits in memory. Correctness comes first: quoting, field types, linked records, and recovering from a partial failure matter more than a bigger number.
An idea borrowed from video games
One of our favorite analogies comes from large online games. Star Citizen, for example, streams in only the part of its world near each player and sends each change only to the players and servers that need it, while the rest of the universe stays stored.
A business is not a game. A game can tolerate a briefly inconsistent world, and your accounting cannot. But the organizing idea carries over well: keep everything safely stored, keep what you are working on close at hand, and send each change only where it is needed.
Security, stated plainly
Records and files Phoundri stores in Cloudflare D1 and R2 are encrypted at rest by Cloudflare, and data travels over encrypted connections. The copy kept on your device for offline work is not yet encrypted by Phoundri itself. It relies on your browser's protections and your device's own disk encryption. Adding application-level encryption is planned, and it comes with real tradeoffs: an encrypted copy needs a key to open, which can mean an unlock step, and encryption never protects an unlocked screen from malware or a malicious browser extension.
We also design with government security frameworks in mind, including NIST SP 800-53, NIST SP 800-171, FIPS 140-3, GovRAMP, and FedRAMP. Designing with a standard in mind is not the same as meeting it. Phoundri does not hold FedRAMP certification, any GovRAMP status, a SOC 2 report, ISO/IEC 27001 certification, or FIPS 140-3 validation today. When we do, we will say so with evidence.
What we are working toward
The goal is software you don't outgrow. A business should be able to go from a few hundred records to a few million without switching platforms, without losing the connections between its information, and without its everyday screens getting slower along the way.
Some of that exists today. Much of it is still engineering ahead of us, and we will keep saying which is which. For the architecture, the tradeoffs, and the sources behind every claim here, read the full white paper: Beyond the Database: Building Software That Scales Without Slowing Down.