Truly Scalable

Unlimited users, tables and rows in jestor

When you’re talking about processes and structures, there’s a very important detail you must take into consideration before choosing a platform to store your data: limitations.

Or rather, which platform won’t impose limitations that act against growth.

Traditionally, many different software will limit you in one way or the other:

• Adding a user adds to the cost, regardless of whether it’ll be a heavy user or just someone who needs to check some information every now and then;
• You’ll have a limited number of tables or workspaces you can create, so you’ll need to be thoughtful about what you’re building. Sometimes, this means creating inefficient  structures for the sake of reducing costs;
• You’ll have a maximum number of records or rows per table. This is one of the worst types of limitations, as it can lead you to splitting a database in two and making a mess out of your data.

When we say those limitations work against growth, it’s because most of the time they’re not a true measure of how large your operation is, neither of how much the platform is helping you successfully run this operation.

• Going from one user to two doesn’t mean your operation has doubled in size;
• Needing three different connected tables doesn’t mean your operation is three times larger than an operation that can run with one, just that you need to structure information in a different way;
• Steadily reaching the maximum amount of rows in the course of a year doesn’t mean you’re an Enterprise plan sized company;

To really reflect your operation size and measure how much we’re helping you, jestor instead relies on a usage based model. Plans have action tiers, which means we only grow when your company grows. 

Unlimited users makes jestor better

jestor can be amazing for solo users. We’ve seen it before: designers, developers, lawyers, architects . . . with jestor anyone can create a unique structure that perfectly fits their workflows and do amazing work on their own. 

However, jestor can become even more powerful when more people use it. That’s because it gives you a lot of flexibility on how to get the most out of those users:

1. You can have users with full access to help you build your jestor;
2. You can have team members with limited access levels to see or insert data without having to go through bureaucratic steps (such as emailing the person with access to the platform);
3. You can even have clients that only have access to data regarding them, so even if you’re a freelancer jestor can help you work better and faster on projects.

So, to help you build the process you want to build, any jestor plan has unlimited users: you can add as many as you want and not be charged extra for it. Want to keep track of OKRs on jestor and grant access to your team? No problem: just add them.

No database is scalable without unlimited records

There’s no point in creating a scalable process if it has an expiration date, and you shouldn’t be punished for successfully scaling up.

It’s common for software to impose a limitation on the number of records or rows you can have on a table, but why? Usually this only serves as a way to enforce more expensive plans, but sometimes it can be as bad as having no way of increasing the number of records on a table.

This can lead to two things:

1. Having to manually extract the data from the table and starting anew, losing immediate access to important history;
2. Having to recreate the process on a different table, splitting the data into separate databases, hurting your company’s processes as a whole.

In jestor, any table can have unlimited records. If a process is successful and scales up, you won’t have to worry about it stopping due to arbitrary limitations on the database. You can rest assured it’ll keep running smoothly and focus on growing rather than preventing chaos.

Size is less important to growth than pace

One last important thing about usage based models is that it doesn’t punish companies that have a lot of legacy data.

Imagine a company that has accrued a sizable database over the course of a year. Let’s say, for example, that they have a table of 6,000 leads on their database.

Now, let’s imagine a different company that started their operation last quarter. They had 1,000 leads the first month, then 2,000 the second, and finally 3,000 leads in the last month. Both companies now have a database of the same size.

Of course, the latter is probably more complex than the former: you’ll need a tighter process to deal with 3,000 leads per month as opposed to a 1,000. More automated processes, a bigger team, efficient communication. 

Even though right now they’re “the same size,” one of them is growing while the other is at a steady pace. Even so, most software will treat them the same: do you need bigger tables? Upgrade your plan. 

This is the kind of arbitrary limitation that hurts a company with legacy data. Their plan needs an upgrade whether the company grows or not. This means costs go up, but earnings remain the same.

With an usage based model, there’s no arbitrary limit: the former company can stay on their plan, and only upgrade when they start to grow. 

So, if you need to halt down growth to prepare strategically, don’t worry: there’s no arbitrary wall coming your way. 

Learn more about the plans

If you wish to understand more about how the plans work, just check out our Plans page to find everything you need to know.