We are a bunch of passionate devs having fun building practical products together. To do so, we follow the following principles
We reduce scope
“Focus Narrow, Deliver Big: Less really is more.”
- What to do
- Breaking down large features into smaller, manageable chunks to ensure quicker delivery.
- Prioritizing must-have features over nice-to-have ones to focus on core functionality.
- Saying “no” to features that don’t contribute to the main objective or postponing for future iterations.
- What to avoid
- Overcommitting to too many features at once.
- Spending time on polishing non-essential elements or perfecting UI components before validating the core.
- Failing to clearly define what’s in or out of scope, leading to scope creep.
We ship early
“Ship Sooner, Learn Faster: Early delivery for quicker feedback.”
- What to do
- Releasing minimum viable products (MVPs) to get feedback from users quickly.
- Focusing on simplicity, while caring for readability, performance and scalability expectations are met
- Prioritizing time-to-market over exhaustive development, even if it means the first version has known limitations.
- What to avoid
- Waiting for a product to be “perfect” before releasing it.
- Ignoring early customer feedback or postponing releases due to minor issues.
- Spending too much time on internal polishing without shipping anything.
We iterate, and improve
“Learn Fast, Adapt Faster: Every step teaches us something new.”“
- What to do
- Analyzing feedback from users or customers after each release and using it to shape future iterations.
- Running experiments and collecting data to inform decisions.
- Regularly conducting retrospectives to identify what worked well and where improvements are needed.
- What to avoid
- Sticking rigidly to the original plan without adjusting based on new information.
- Ignoring feedback or failing to collect it after each iteration.
- Treating a release as a final solution rather than a stepping stone to the next version.
We take ownership
“Own It, Lead It: Great outcomes start with taking responsibility.”
- What to do
- Owning the entire lifecycle of our code, from development to production and maintenance.
- Actively engaging in problem-solving, taking responsibility for identifying and fixing issues rather than passing them off.
- Communicating proactively about project status, blockers, trade offs, or failures, and following through on commitments.
- What to avoid
- Blaming other teams or external factors for project delays or failures.
- Failing to address production issues promptly or waiting for someone else to solve the problem.
- Over-relying on PMs or others for validation without taking responsibility for writing CI tests or reviewing and owning your deploy.
We drive revenue
“Build for Impact: Create what counts and drives revenue.”
- What to do
- Prioritizing features and fixes that have a direct impact on revenue growth, such as improving customer retention or enabling new sales opportunities.
- Collaborating with sales, marketing, and product teams to understand how engineering can best support revenue goals.
- Measuring the impact of releases on key revenue metrics and making adjustments to improve outcomes.
- What to avoid
- Focusing too much on technical elegance or side projects that don’t have a clear connection to revenue.
- Neglecting to consider how changes impact the customer experience or the sales cycle, leading to lost revenue opportunities.
- Building features without clearly understanding how they contribute to customer acquisition, retention, or upsell opportunities.