Skip to content

Our battle-tested framework enables rapid development and growth.

Balanced Agile Process

Agile is both loved and hated by people who adopt it. When agile is used for its user centricity and enhancing collaboration, it works well. When it is used to micro-manage people and enforce processes which don’t go with natural rhythm of self-organising teams, it becomes ineffective.

We have developed a process which stays true to the core agile values while allowing for modern practices such as continuous deployment. Our version of agile is based on Kanban with extensive definition of done for every user story. This approach results in just the right amount of engineering with no technical debts.

Since we don’t follow Scrum rituals, the process is light weight and truly agile; allowing changes and deployments at any given time. The process is perfect for initial product development, and can be scaled into later phases of the product lifecycle as well.

Cloud-native Architecture

Cloud-native refers to set of tools and practices which enable quick scale, reduction of dependencies and ability to rapidly deploy new versions of the software. If you want to build a scalable product, then cloud-native technologies are the way to go.

While cloud-native technologies such as Docker, Kubernetes and the overall micro-services architecture with components such as message queues are usually considered to be complicated, our teams are adept at them after having developed with these tool-chains for several customers.

The result of using cloud-native technologies is that you launch a product which you don’t have to refactor when you start to scale. These technologies can be deployed on any public cloud and hence there is no vendor lock-in.

DevOps Practices

Your product is as good as the people who work on it and the processes they adopt. Modern platforms require swift changes and continuous flow of updates without breaking things. DevOps refers to a set of practices for continuous integration and testing of new code.

All of our projects make extensive use of Git for source control, continuous integration servers for running various tests on the code, and releasing once the changes have met all the criteria (definition of done). Every new change is staged in a preview environment before it makes it way to the more critical environments. Our environments are managed with infrastructure-as-code tools and monitoring and alerting are configured as a standard.

Combining the DevOps practices with our balanced agile process and cloud-native technologies, we have a well oiled machine which continues to produce high quality code at a swift pace. 

Open Source Components

Open source software has a major contribution in bringing the digital revolution in past few decades. Not only are open source software free, but the good projects have large communities around them, which means they get regular updates.

It is almost impossible to build a modern product without using open source components in it. We take this a little further and make sure that we use open source components wherever an option is available. This approach minimises vendor lock-in and opens up possibilities for future expansion without having to refactor the code base.

Open source does come with its challenges especially in security, and therefore we use vulnerability scanning as a standard at different levels of the infrastructure. 

Integrated Growth Stack

Modern products are data driven and decisions around building new features, running marketing campaigns, and providing support to your customers are all made with the help of data. Measuring growth metrics are vital to know how your customers are using your product and where you can make improvements to enhance financial performance.

Since we utilise cloud-native architectures and build our backends to be event driven, we also stream these events to customer data platforms, analytics and marketing automation tools so that this data can be used by your sales, success and marketing teams. 

By have a well designed and integrated growth stack from the very beginning, your product will be ready for scale from day one.

Our Preferred Stack

All
Product
Design
Fullstack
Machine Learning
Infrastructure
miro-logo
Miro
jira-logo
Jira
slack-logo
Slack
github-logo
GitHub
figma-logo
Figma
react-logo
React JS
reactnative-logo
React Native
electron-logo
Electron JS
node-logo
NodeJS
python-logo
Python
kafka-logo
Kafka
postgresql-logo
PostgreSQL
mongo-logo
Mongo DB
elastic-logo
Elastic Search
redis-logo
Redis
clickhouse-logo
ClickHouse
docker-logo
Docker
kubernetes-icon
Kubernetes
helm-logo
Helm
terraform-logo
Terraform
drone-logo
Drone CI
cypress-logo
Cypress
ambassador-logo
Ambassador Gateway
rudderstack-logo
RudderStack
posthog-logo
PostHog
tensorflow-icon
TensorFlow
spark-icon
Apache Spark
sentry-logo
Sentry
rasa-logo
Rasa NLU
postman-logo
Postman
drive-logo
Google Drive
gcp-logo
Google Cloud
aws-logo
Amazon Web Services
cloudflare-logo
Cloudflare

Common Questions

All the time. We learn new things, discover flaws with some of our choices, and continuously make improvements to our way of doing things.

Most open source platforms we use do come with their hosted versions and we do use them. The point is the ability to host your own when you need to.

We have a clear preference for Google Cloud Platform because of its hosted Kubernetes service. The Google Kubernetes Engine is the best hosted Kubernetes option out there.

Kubernetes is the most important platform in our entire framework and therefore our choice of cloud provider is dictated by it.

We use trunk based development as it suits our model of continuous delivery and extensive automated testing.

Our typical definition of done includes unit tests, integration tests, and end-to-end tests on a preview environment identical to production. The preview environment is also tested manually before the code is merged and the story is accepted.

Our typical micro-services backend includes a Ambassador (an API gateway) and Kafka (a message queue). 

All requests from the outside world lands on the API gateway which authorises these requests and relays them to appropriate services.

We de-couple micro services from each other as much as possible and avoid direct HTTP requests. We use reactive event architecture to establish inter-services communication. 

Monoliths won’t scale and won’t support advanced use cases typically required by modern apps.

If you don’t expect your product to scale, and the requirements are simple enough, then you should use a monolith framework such as Django or Laravel by all means.

Micro-services are the way to go if you want to build a product which can scale and where you can keep adding features without having to refactor the architecture of the product.