We release our main web application multiple times per day; our automated deployments only take one click to take a change from CI to staging to production. Deploying frequently is an engineering team superpower that we take full advantage of: it reduces risk by spreading changes out over time and allows our team to get code out delivering value as fast as possible.
We hate repetitive, error-prone work in our development processes. We invest heavily in automating and abstracting as much as possible, which gives each engineer more and more leverage the more we grow. At Tegus, engineering teams get more productive over time, not less.
High quality automated tests are the key to confidently making changes at the speed we’re shooting for. We continuously invest in our test suites and are experts and finding the right way to exercise new changes.
The shared backend for our applications is written in Ruby on Rails. For nearly 17 years Rails has been a fantastic framework for happy and productive engineers. We use a particular variant of the “modular monolith” pattern within our application to keep our architecture as clean as possible.
The Tegus product involves ingesting 3rd party datasets - company data, SEC filings, earnings calls, etc. Python is great for data processing and manipulation and a good foundation for the machine learning that we expect to be coming soon.
Our web frontend applications are written entirely in Vue and Typescript. We find the simple, batteries-included approach of Vue gives us a ton of power when building new features, and Typescript helps us catch errors well before they’re visible to our customers.
We use GraphQL across all of our APIs for two reasons. First, the flexibility of GraphQL allows many new features to be prototyped without any backend changes at all. Second, GraphQL gives us a machine-readable API schema definition, which we use to automate many parts of our development workflow.
We’re hosted at AWS and take advantage of their amazing technologies so we don’t have to re-invent what they have built for us.
Understand previous information. How are users using the product today? Where are current product experiences falling short of their expectations? How can we improve the content discovery experience?
Set the direction through broad exploration. Based on earlier knowledge, we sketch and wireframe "blue sky" concepts and iterate on them - not limited by current technologies. Designers sketch and wireframe to ensure they’re exploring the solution space broadly. We leverage variable fidelity to bring concepts alive to socialize them internally and gather feedback from users.
Cross-functional squad aligns on vision and top priorities then kickoff the work to figure out how we'll solve the opportunity and define success. During the kickoff and initial investigation, we analyze the current state, identify deltas, capture vision confidence level, and determine a plan on how to tackle it. In situations where a big product change could be complicated or even controversial, we run a product workshop with the squad, and other leadership, to ensure everyone understands the scope of the problem and potential repercussions.
This phase attempts to answer one crucial question: do we have enough information to move forward? This involves an exploration of the tech involved, working through broad concepts and rapid iterative prototyping to critique, get internal feedback, and validate with users. A combination of qualitative and quantitative metrics are used to gauge the success of these experiments.
After the experiments, we use Komodo, our design system, as the foundation to build and ship the product or feature on a common tech stack with a UI that aligns with the broader Tegus user experience. We monitor and measure the impact of the work. Based on learnings, the team makes any necessary improvements to the product, then additional iterations may be needed.