Our founder, Mike, was our very first engineer. He wrote a substantial portion of Visor’s main architecture — including the front-end SPA and the the architecture of the realtime data layer that powers Visor’s collaborative spreadsheet. It should come as no surprise, then, that engineering is a highly-valued part of Visor’s team and culture.
While Mike doesn’t code regularly anymore, we build with a balanced approach between a scrappy startup with minimal process to a mid-size company with some automation and systems in place to create order and predictability. While we maintain high standards, we organize and manage our engineering team with the empathy that comes from having been in the trenches.
Code collaboration & CI/CD
We use Github for code collaboration with mandatory PRs and code reviews before anything makes its way into the product. In the repository for our front end, we have an
env/prod branch. PRs merge into
env/dev, after being reviewed by at least one more team member. Merging into
env/dev automatically deploys the front-end to a staging environment. We then create PRs to merge
env/prod for each release. We release generally as soon as we have updates to push, which varies depending on the scale of the projects we’re working on and the scale of our team. We will generally release at least three times per week.
We currently run human testing for QA, since the foundation of the product has been moving a bit too quickly for us to make use of more automated E2E testing. We’re actively considering ways to improve our efforts around QA.
We use Jira for project management. And, of course, we use Visor as a way to organize, plan, and communicate about our work for a given week. We use a kanban-like approach — each week we plan out the work we’d like to have ready for engineering. And then the engineering team will meet up periodically during the week to divide up the work.
We use Figma for design and Zeplin for design documentation.
Our front-end uses VueJS (2.7) and deploys via AWS Cloudfront for all static assets. We aggressively use code splitting to reduce bundle size. We maintain our own UI library, which has its own repo and gets included in our main front-end repo as a Git submodule.
Our back-end is split across about 12 different services, each of which has its own repo and deploys via AWS elastic beanstalk to auto-scaling environments. We use Python + Django for our back-end. We generally use Postgres for persistence, with Redis + Celery for our queues.
We use AWS API Gateway to manage our sockets, which power CloudStore’s realtime data engine.
We have an in-house data warehouse running on AWS redshift, which is where we send our telemetry data from the product (via a custom-built telemetry engine).
We maintain documentation in our internal Notion workspace. All engineers are asked to maintain this source of truth. This is also a critical resource we use for onboarding new team members.