How We Work

We begin a project by meeting and discussing with the stakeholders of the project to understand their goals, expectations, and constraints. When needed, we conduct user and market research to gain deeper insights into the end-user experience and behavior. This may include interviews, usability testing, competitor analysis, surveys, and other forms of observations. The goal is to make sure we truly understand how the product is going to be used in real life.

After gaining a thorough understanding of the required system, we then develop wireframes. These wireframes are turned into interactive prototypes (usually Figma designs) so that we can get feedback early. Based on the feedback, prototypes are improved until they are finalized.

Before the development starts, the requirements are translated to user stories. These requirements first go into the backlog, which is also continuously refined and groomed in collaboration with the team and the stakeholders. Sprints are created from this backlog of stories by grouping them together based on priority and related functionalities. Sprints are executed one-by-one. Sprints are usually two-weeks long, but sometimes, a one-week sprint is also created if the team needs to deliver a quick iteration, or validate a small feature before larger release. Each user story and feature is tested after completion. When a sprint completes, a thorough testing is done and shared with stakeholders for feedback. Areas for improvement are identified and the changes are incorporated in subsequent sprints. This build-test-feedback-improve loop continues until the product is ready.

We also borrow concepts from Kanban and Lean in our methodology. We love how these philosophies promote continuous delivery instead of blocks.We use Kanban boards to visualize the tasks. Our usual Kanban board template includes the columns - Backlog, To Do, In Progress, In Review, Done. The number of tasks in each column gives us a good indication of how we are performing. A low number of tasks on the 'To Do' column suggests we need a planning meeting to pull in new tasks from the backlog. Too many pending items in the 'To Do' and 'In Progress' column suggests the velocity is low. Limits are also placed on the number of tasks in each column so as to encourage focus, prevent overload, and maintain a steady workflow.

We learn from proven frameworks like Scrum and Kanban and adapt their ideas to fit each project we work on.

We use Plane, an open source project management and knowledge management software to streamline our process.

Synchronization

We do daily wrap-ups. We have a worklog system developed in-house that automatically posts in #daily-updates channel in appropriate group. Team members sync with each other through these. When the team needs to brainstorm, we come together in our "studio" and discuss and share ideas.

We do daily standup meetings in projects that follow the Scrum framework. We also do daily standups in projects not strictly following the Scrum framework when a large team is allocated and the project spans months of development.

Gemba Walk

Team leads are encouraged to do Gemba Walks. This can be physical visits to the workstation of team members to talk about the features in progress and how they are going. Or it can be a virtual walk-in which means observing the work being done remotely to learn how products are being developed and identify any opportunities for improvement.

Developer Collaboration Practices

We believe software is best built together. From design discussions to code reviews, collaboration is at the heart of our development process. One of the key practices we follow is pair programming, which helps share knowledge and speeds up learning for junior developers. Even experienced developers often pick up useful tips from their peers during the process.

We also practice regular code reviews by both peers and senior developers to maintain code quality and encourage continuous improvement.

Open Source

We're big supporters of open-source software. Our development machines run Linux by default, and we also contribute back by open-sourcing several of our own projects. You can explore them on our GitHub.

We also utilize several open source systems to streamline our processes - Plane, for project management; OrangeHRM for human resource management; TwentyCRM for customer relationship; Coolify/Dokploy for deployment management.

Tests

In our philosophy, testing is not solely the responsibility of the QA team. Software developers are equally accountable for the quality of the systems they build. We write end-to-end tests to ensure that all critical workflows function as expected. We enforce unit tests and full test coverage for crucial parts of the system or when we anticipate high complexity, frequent changes, or potential business risk.

Focus on Core Work

Most of us are passionate software developers who enjoy building things rather than spending time in meetings and other administrative tasks. We consider meetings and excessive communication as overhead and therefore try to keep them minimal. We also prefer async communication because it lets everyone stay focused and respond in their own time without interrupting deep work.

However, some overhead is inevitable. We can't improve what we don't measure. To track progress, assess project profitability, and make informed decisions, certain records and non-core tasks are necessary. While these activities are unavoidable, we try to minimize their impact by automating as much as possible. For instance, we built an internal worklog system that's simple, quick to use, and tailored specifically to our workflow - making the process far less time-consuming.

By keeping overhead low and automating wherever we can, we ensure our team stays focused on what we do best - building great software.