How Visor Achieves 10x Engineering Velocity Over Tech Giants

Tech innovation moves fast – blink and you’re behind.

Yesterday’s pioneers become today’s laggards without constantly moving towards the next goal. But staying ahead isn’t just about pushing boundaries; it’s about meeting ever-rising customer expectations—an expensive and relentless challenge.

Since its inception, Visor has been tackling the expectation that all software will update in realtime: no save buttons, instant connection to collaborators, and a level of UI responsiveness that tech giants like Google and Slack make us take for granted.

But any product manager or engineer knows just how complicated and time-consuming it is to rise to each new bar.

There are solutions out there aimed at this. Technologies like Supabase make enabling realtime capabilities at least a bit easier, but from an engineer’s eye there’s still expansive boilerplate codes and manual state management to contend with.

That’s why we made it a priority to have realtime connection be “free” – a totally automatic default state of our technology stack. 

You read that right. Not only is our team able to build features by writing less code, but the features are always automatically getting the benefits of realtime updates as the distributed global state changes.

We found a way to store and propagate realtime data across clients elegantly, efficiently, and in a way that empowers us as engineers. It’s called CloudStore and, as two industry veterans, it’s revolutionized the way we program.

Who we are

With a combined 25 years of programming experience between us, we’ve seen a lot, built a lot, and have our own opinions on the best way to handle most programming conundrums.

With 16 years of programming experience, Samuel Batista is Visor’s principal software engineer. This has been a dynamic role and, since he joined the team in 2024, he’s been shifting focus to where he’s needed most, but always with an eye for identifying the next big problem for the business. Before Visor, Sam was at Salesforce for several years and before that was a UI engineer for video game companies like Big Huge and Firaxis.

Tyler Diminick has been a senior software engineer at Visor since 2023. His role is mostly focused on the frontend of the app, including features, upkeep, and making sure the UI is always smooth and seamless. Prior to Visor, Tyler crafted code at Amazon for several years.

Something customers say about us all the time is how responsive the Visor team is to feedback, and how we involve our users in our roadmap. We’re co-creating this article to deep dive on that speed and flexibility.

We want our customers to understand how Visor is able to move so quickly. But we also want to explore ways the technology we use to develop Visor can do so much more. So we’re going to talk more about our previous experiences at Amazon, Salesforce, and a few other companies to shed some light on what makes engineering at Visor so different – and so much better.

CloudStore and all-object programming

CloudStore is, at its most basic, a database. CloudStore is where we keep and organize all of Visor’s data. All of it. Everything in the app is saved as an object in CloudStore – from elements of a workbook to the actions the app takes to connect integrations. If you are familiar with document databases (like MongoDB), then you already understand part of the concept.

“If my team at Amazon had something like Visor’s CloudStore technology, they’d move 10x as fast.”

One critical difference that sets CloudStore apart is the tight coupling between the database and a highly-opinionated client SDK, resulting in an exceptionally terse, fast, and flexible developer experience (DX). What takes other tech stacks dozens of lines of code to accomplish (sometimes across frontend and backend) CloudStore can do in just one line in the client. This simple syntax is enabled by JavaScript proxies, an often overlooked metaprogramming feature that launched in 2015 (and we began using in 2016).

Crucially, CloudStore also establishes subscriptions by default for realtime updates to all objects (and the relationships between those objects) to keep those objects in sync, wherever they are, including other clients and the server. Subscriptions happen automatically when objects are created as well as when they are loaded. Put simply, the CloudStore server keeps track of the objects sent to (or created by) individual web clients, using websockets to send updates as needed.

That means that changes that you make to objects automatically get stored and published to other subscribers. In our product, this means that updates to record data in the cells get propagated in realtime to show up in other tabs on the same device and to customers with tabs open on other devices. Even if two people edit the same record at the same time, CloudStore will create a unified final version for both of them using a last-write-wins (LWW) policy.

Because of how our UI framework, Vue, renders the UI based on the state of these objects, it automatically detects changes to the objects (whether they happen locally or arrive via subscription) and updates the UI.

Said another way: CloudStore makes any UI built with a reactive UI library realtime by default.

Here is a comparison showing how creating an object in the database with CloudStore compares to some popular technologies like Supabase, firebase, and MongoDB using Realm.

Supabase Code

Firebase code

MongoDB Realm code

CloudStore code

CloudStore syntax is very terse and easy to read. Objects automatically get subscribed to updates, which the system handles internally as they are sent and received. Error handling is done at a global level, with automatic retrying and offline/online management.

And this all happens simultaneously in the backend of Visor, making it seamless for users. And that’s what we find ironic about such a powerful system: it shows up all across the app, but the users don’t even know it’s there.

This is in contrast to the old way of doing cloud-based data storage. In that case, you’d have a database saved in the cloud and would load the data from it with help from a server as an intermediary. Then, as changes happened in the client, you’d update the database, load the result, and update the client’s state.

From an engineering perspective, this is radically tedious as you have to manage three separate systems: the client, the server, and the database. Every new feature addition or update requires keeping all three of these systems up-to-date. Not to mention, if you want to add any realtime behavior, you need to manage a fourth system for subscribing to database changes, sending them to the clients, and surgically merging the updates into the state. It’s shocking that this is commonly considered the “state of the art” in 2025.

Supabase code

Firebase code

MongoDB Realm code

CloudStore code

Updating CloudStore objects is as easy as updating local JavaScript objects. Yet it comes with the added benefit of syncing to the server and propagating changes to all clients with a copy of the same record.

Using Visor’s CloudStore, there’s one globally distributed state, maintained on the server but also running in all the clients. You don’t have a projection of the state you need to maintain and sync – you have the one, global state. In this world, you directly update the state from the client, and it syncs automatically to the database. It also automatically updates any other clients in the world that have these objects. So instead of managing four systems, there’s just one: the global state everyone shares.

CloudStore makes a huge difference for the experience of using Visor. But it also makes a big difference for the engineers on our team. Using CloudStore, engineers aren’t chasing after data and trying to manage the flow between server and client. They’re just working with one unified world state they can easily change. It is exceedingly rare for new features to require changes on the server. This dramatically reduces the cost of innovation (in both time and human resources).

You could use CloudStore to create a totally different application. Anything where you need live data across clients (which is the whole internet) could use CloudStore to do that.

Similar to how the venerable Docker container technology emerged from internal needs at the company (formerly called “DotCloud”, for the historian), CloudStore emerged from the needs of our company. We’ve refined this technology over nearly 10 years of building Visor, and it has grown to be robust, performant, and an absolute joy to work with. And, one day, we have a vision of unleashing it to the world. 

Empowering engineers

CloudStore’s SDK largely frees Visor’s developers from having to write repetitive boilerplate code. It simplifies code by handling mutations synchronously (letting the SDK manage the asynchronous parts). It also spares developers from needing to add error-handling code to every state mutation, instead relying on a global error handler to handle online/offline status, timeouts, and extremely rare system errors.

At the time of writing, we’ve recently updated our product’s pricing and packaging model. We needed to change several things within our app to support that new flow. And, though the rest of the team contributed, largely it was a solo job on Sam’s part.

Just one engineer was able to revamp the entire pricing checkout flow, checkout screen after checkout screen. Out of this entire massive project, only two backend changes were needed: a call to the Stripe API to get a checkout page URL and a server-side webhook handler for updating license objects based on stripe events. (Even the license object, indicating a user’s plan and entitlements, is a CloudStore object). Every single other change was managed by changes in the frontend using CloudStore. We hardly broke a sweat!

“I knew that any team with this technology would have an unfair advantage in the marketplace.”

At most other places we’ve worked, if you want to make a change to the app, you’ll need to make a change to the frontend and then write a backend endpoint. You then need to make sure they talk to one another, and there’s always some issue or another in that process. It can be very draining. So our speed updating the product at Visor was invigorating.

The back-end-to-front-end dance is not even a consideration. Once you’ve defined your objects, everything uses the same tunnel. You just need to find a CloudStore object on the front end. You can give it any properties that you want (we have a strict typing system in place to avoid chaos!). And then – like magic! – it’s automatically saved in the database. No backend endpoints needed; CloudStore has a unified pipeline for managing objects that saves new ones automatically.

This stands out all the more when you compare it to the places we’ve worked before. What at Amazon or Salesforce would take a week takes the Visor team minutes. That’s not just because our company is smaller; CloudStore cuts the amount of work by a factor of 10x – seriously, we’ve counted.

Visor vs Salesforce and Amazon

Smaller companies, startups in particular, are famous for their agility. They’re able to change plans according to new information, pivot, and take action fast – much faster than huge companies with hundreds of people will ever be able to.

But Visor is uniquely agile because of things like CloudStore, and it stands out – especially to anyone who has experience with bigger teams.

Sam and Salesforce

My years at Salesforce were when it had close to 100,000 employees. I was able to see how a company of that size makes it work and how it breaks up into smaller teams and smaller units. There’s a hierarchy that’s necessary to manage all of that scale and scope and still have accountability at the end of the day. I absolutely found at Salesforce that my work was siloed and that we couldn’t, as engineers, broadcast our work across the business, even if it would have produced better results.

In contrast, Visor thrives on being nimble and collaborative. We want the frontend and backend of the app to be connected instantly so that, if data changes as a result of an operation, the UI is reactive immediately – and vice versa. The way we’ve solved that internally feels like such a good reflection of the way we think about problem solving overall.

We lean into technology called proxies in JavaScript, which is definitely a novel approach. I haven’t seen proxies used at scale and to such a specificity of product as we have. It’s outside the box thinking that ends up making everything faster and easier from an engineering perspective. By using JavaScript, and proxies specifically, it leads to an awesome development experience.

When our CEO, Mike, explained CloudStore to me, I was immediately compelled. CloudStore was a very significant part of why I decided to join Visor in the first place. I knew that any team with this technology would have an unfair advantage in the marketplace.

Salesforce had a lot of proprietary internal tools and systems that are incompatible with external systems – enough to make it harder to innovate. If Salesforce had had CloudStore technology, they might have been able to pivot more quickly, and the value of cross-team collaboration would have been instantly obvious. This is a different type of connection between parts of the app, and it results in a different type of connection between teams and people, too.

Tyler and Amazon

Just like Sam, I dealt with a lot of slow movement and siloed systems at Amazon. Even a tiny feature update would have to go through multiple levels of approval; we just weren’t able to be agile. Whereas at Visor, we can achieve in a day what Amazon would have taken weeks to deliver (and that’s not just about culture – it’s our revolutionary technology that makes us faster).

CloudStore’s visualizer in action

Because CloudStore is so powerful and flexible, we feel secure making changes to the product without putting up speedbumps, knowing that user data will always be protected.

And because we uniformly use CloudStore as our database, we can apply it to a much wider and more creative range of projects than I’ve ever seen at a bigger company. A good example of this is our “VESPA” program – that’s Visor Entrepreneurial Special Project Activity. It’s a way for the team to introduce interesting new projects. We use this program to build out new internal tools that are, in my opinion, of the same caliber as the ones we used at Amazon. And many of our tools improve the experience of working with CloudStore.

For example, we have a debugging panel where we can see our CloudStore objects in a 2-dimensional graph. I built a page within that panel so that we can see all the events that get sent out as they happen. As you’re building events or testing events, you’re able to easily see each event and all the data that gets sent with it. So if something is going wrong, you’re able to see it right away.

Our culture, our processes, and our technology all inform one another, and it’s extremely cool to see it happen live. If my team at Amazon had something like Visor’s CloudStore technology, they’d move 10x as fast and need only half as many people to do the work – while being able to iterate on product configurations becomes so much easier.

CloudStore is one major example of the way that Visor moves quickly – and it’s also why it could be so much more than just a great app.

CloudStore: Our secret weapon for gaining agility

While smaller teams at newer companies are always more agile than their enterprise counterparts, as engineers, we feel that Visor is uniquely agile and powerful because of our technology, not just our size and culture.

CloudStore is a novel take on data storage and object-oriented programming that unlocks a meaningful boost that sets us apart. But CloudStore is a standalone technology that could power any product. And we plan one day to make it more widely available as its own product so all teams can benefit from its incredible power and so that more engineers can experience the delightful experience we enjoy every day.

Learn more about Visor or try it for yourself.

Samuel Batista

Samuel Batista

A front-end specialist with a long career building user interfaces for video games and web applications, with experience writing & debugging server applications; a versatile full stack engineer who joined Visor at just the right time.