Design. Build. Ship.

We design and build mobile apps, SaaS & marketplaces

CountryDevs is an app design and development studio in Bengaluru, India. We work with founders and businesses in India and around the world, and take a product from the first sketch to the App Store, Google Play and the web, with design and engineering in one team. Every project starts with a two-week Discovery Sprint, so you see the screens and the plan before any code is written.

Start a Project How We Work

Plan firstscreens before any code
One teamfrom design to launch
BengaluruHQ · clients worldwide

Terminal

$ npm run build

✓ Build complete

GET

POST

PUT

Live

{

}

What we build

Seven kinds of product, and how we build each one

Most of what we build is one of these seven. Pick one to see the problem it solves, what we build for it, how we approach it and when it isn't the right fit.

Two-sided marketplace apps

A marketplace is three products that have to agree with each other: the customer app, the provider app and the admin console behind them. A booking changes state in all three at once, and money moves between people who never meet. Most half-built marketplaces fail at exactly that seam: the provider sees one status, the customer another, and the payout doesn't match the payment.

What we build

Customer and provider apps for Android and iPhone
Bookings, packages, wallets and payouts
An admin console for disputes, refunds and verification
Chat and notifications that both sides can rely on

How we approach it

We map the money first: who pays, when the platform takes its share, when the provider is paid and what happens on a cancellation. Then we design the booking states once and use the same states in every app and the console, so a status can never mean two different things. On Trainr, a Dubai fitness marketplace, clients pay through Stripe and trainers are paid out from the same records the admin console reads.

Questions we settle with you first

Who carries the risk on a cancellation or a no-show: the customer, the provider or the platform?
When is a provider paid: after each job, weekly, or when a customer confirms?
Which side do you launch first, and how do you get the other side on board?

Not the right fit: If you only need a listing directory with no bookings or payments, a website will serve you better than a marketplace app.

How we build marketplace apps

CPU

RAM

NET

Who we are

A design and engineering studio that stays with a product from the first sketch to the hundredth release.

CountryDevs is a product studio in Bengaluru. We design and build mobile apps, web apps, SaaS products and marketplaces, and we look after them once they are live. The same team works on a product from the first conversation to the store listing and beyond: the people who drew the screens are in the room when they are built, and the engineers who built them are the ones who fix them later.

That continuity is the point. Most problems in software projects happen at handoffs, between the agency that designed it and the one that built it, or between the team that launched it and the one that has to keep it running. We remove those handoffs by keeping design, engineering and support in one place, with direct access for you to the people doing the work.

We build quickly because we use modern AI-assisted tooling for the routine parts of the work, and we build carefully because a senior engineer reviews every change before it ships. You get the pace without the mess: software a new developer can open, read and keep improving.

We also say no. If an app would serve you worse than a website, if a feature costs more to run than it earns, or if a deadline can only be met by skipping tests, we tell you before it is built, not after.

Company: Country Devs LLP
Headquarters: Bengaluru, India
Working since: 2021
Team model: Design and engineering in one team

More about the studio →

What we do

Design. Build. Ship. One team for all three

The people who plan your product are the people who build it and take it live, so nothing is lost between stages. Hire us for one stage or all three.

Design

Brands, interfaces and prototypes, designed to be built.

What an engagement looks like

A design engagement starts with your users and the journeys they repeat, not with a mood board. You see flows first, then screens, then a prototype you can put in front of real people, and every file is prepared so engineers can build from it without guessing.

See design services

Build

Mobile apps, web apps, SaaS and websites, with the backend and admin behind them.

What an engagement looks like

A new build starts with a two-week Discovery Sprint and then runs in milestones, each ending in something you can install. The apps, the backend and the admin console your team runs the business from are built by the same people, so nothing is lost between a front-end team and a back-end one.

See build services

Ship

Store review, servers and the monthly care that keeps a live product working.

What an engagement looks like

Launch is planned from the first milestone: test builds reach your phone through Google Play's internal testing and Apple's TestFlight, and store listings and privacy answers are ready before review. Taking over someone else's app starts with a five-day audit on read-only access, so nothing changes while we look.

See ship services

Product types we have built before, so you don't pay for us to learn them: marketplaces, fitness and training apps, delivery and logistics, AI features and chatbots.

How we work

Eight habits that keep a fast build from breaking

Speed is easy to promise. These are the working habits that let us move quickly and still hand over software that holds up in production.

A written plan before any code
Every feature starts as a short plan: the screens, the data it touches, the edge cases and what could break. You read it before we build, and code that doesn't match the plan doesn't get merged. It is the cheapest place to change your mind: a sentence in a plan costs minutes, the same change in finished code costs days.
Fast tools, senior judgement
We use modern AI-assisted tooling to move quickly through the routine parts of a build. Speed is not the same as quality, so a senior engineer reads every change before it ships, renames what is unclear, simplifies what is clever and throws away what doesn't belong. You get the pace of automation with code a new developer can still follow.
Tests decide, not confidence
A feature is done when its tests pass, not when it looks right on one phone. Before a launch we exercise the API the way the apps will: before Pakka went live, a probe called 260 of its 270 API routes and every failure was explained before release. Anything that moves money gets the closest attention.
The app on your phone while we build
You don't wait for a big reveal at the end. As features land, test builds go to your phone through Google Play's internal testing and Apple's TestFlight, so you try real screens with real data and tell us what feels wrong while it is still cheap to fix.
Every screen, tested like a reviewer would
Before the stores see an app, we walk every screen by hand on real phones: the happy path, the broken network, the wrong input, the large system font. On Pakka two full passes covered every customer and driver screen, the second at both normal and enlarged font sizes, and every defect was fixed and re-checked.
Designed for the running bill, not only the launch
Maps, SMS, storage and AI calls are paid per use, so architecture decisions show up on an invoice every month. We look at what each feature will cost to run before it ships. On Pakka, live tracking was asking for a new route on every location update, about 151 paid calls on a 25-minute trip; it now asks once per leg.
A handover someone else can pick up
Every change is recorded against the feature it belongs to, and the project ends with written documentation: how to run it, deploy it and recover it. When Trainr moved to the client's own developer, the handover covered the deploy steps for each of its server services.
Direct access to the people building it
You talk to the designers and engineers doing the work, not to a layer of account managers relaying messages. Questions get answered by someone who can see the code, and decisions are made in the same conversation instead of a week later.

How a project runs

From the first call to the hundredth release

Five stages, each ending in something you can check. Scroll through them and watch a product take shape: what we do, what you receive, what you decide and how long each stage takes.

Stage 12 weeks
Discovery Sprint
Two weeks of senior work that turn an idea into a plan both sides can build against. We learn who uses the product, the one journey that has to work on day one, the deadline and every system it must talk to: payments, maps, SMS, an existing database. By the end the unknowns are written down instead of discovered halfway through the build.
You receive
- A prioritised scope: what is in the first release and what waits
- User flows for every important journey
- A clickable prototype of the core screens
- The architecture: apps, backend, admin console and integrations
- A risk list covering integrations, data, compliance and open questions
- The build plan, split into milestones you approve one at a time
You decide
- Who the first users are and which journey matters most
- Android, iPhone, web, or which one goes first
- What can wait for the second release
It takes about three short calls of your time: a kick-off, a mid-week scope review with one round of changes, and the final walkthrough. Everything the sprint produces is yours, even if someone else builds the product.
What usually goes wrong here, and how we prevent it
Starting to build from a one-page brief. The questions nobody asked come back mid-build as change requests, and the timeline slips one surprise at a time. The sprint exists to ask them first: every integration, every role, every edge case we can find goes on the risk list before a line of code is written.
What happens in a Discovery Sprint →
Stage 2Runs a step ahead of the build
Design
We design the journeys that matter first, the ones your users repeat every day, and we design them on a phone-sized screen before anything else. Each screen is checked for contrast, touch-target size and what happens when the text is longer than expected. Brand, colour and type become a small design system, so the hundredth screen looks like it belongs with the first.
You receive
- Designed screens for every journey in the first release
- A clickable prototype you can put in front of real users
- A design system: colours, type, spacing and components
- Empty, loading and error states, not only the happy path
You decide
- Approve each journey before it is built
- How your brand should feel on a small screen
Design runs one journey ahead of engineering, so a screen is approved before anyone writes code for it and nobody waits on the other.
What usually goes wrong here, and how we prevent it
Designs that only work with perfect data: a short name, a fast network, a user who never makes a mistake. They look finished in a presentation and fall apart in the app. We design the empty, loading, error and long-text versions of each screen alongside the ideal one, so engineering never has to invent them.
How we approach UI/UX design →
Stage 3Weeks to a few months
Build
One team builds the Android and iPhone apps from one React Native codebase, the backend that serves them and the admin console your team will run the business from. Work is split into milestones that each end in something you can install and use, not a status report. Every change is planned, reviewed by a senior engineer and covered by tests before it is merged.
You receive
- Test builds on your phone as features land
- A working milestone at the end of each stage of the plan
- The admin console alongside the apps, not after them
- A change log that explains why the code is the way it is
You decide
- Accept each milestone, or tell us what is wrong with it
- Trade-offs when a new idea arrives mid-build: swap it in, or schedule it for later
For scale: on Pakka, a delivery platform with customer and driver apps, a business portal and an operations console, the first full delivery worked four weeks after the start and everything was in production in under fifteen weeks. LeafRanger, our own plant-care app, went from first plan to a signed production build in eleven weeks.
What usually goes wrong here, and how we prevent it
Months of work that nobody outside the team has used. Problems then surface all at once, right before launch, when they are most expensive to fix. We keep the product in your hands from the first milestone, and we build the admin console alongside the apps, so the people who will run the business test it with real data early.
How long different builds take →
Stage 4Paced by the store reviews
Launch
Launching is its own piece of work. The stores change their rules every year, and a rejection on launch day costs more than the work to avoid it. We prepare the listings, the privacy answers and the release builds, run a final pass over every screen, and handle the questions reviewers send back until the app is live.
You receive
- Store listings, screenshots and privacy declarations
- Release builds that meet the current store requirements
- A final screen-by-screen pass before submission
- Answers to every reviewer question until approval
You decide
- Which store goes first, if not both at once
- The launch date, once both stores have approved
The rules move: from 31 August 2026 new Android apps must target Android 16, Apple has required Xcode 26 and the iOS 26 SDK since 28 April 2026, and a new personal Google Play account needs 12 testers for 14 days before it can publish to production.
What usually goes wrong here, and how we prevent it
Treating store submission as a button press. Reviewers reject apps for reasons that have nothing to do with the code: a login they can't get past, a permission the app asks for without explaining it, a privacy answer that doesn't match the app. We prepare a reviewer's path through the app and check every permission before submitting.
Our Google Play launch checklist →
Stage 5Monthly, for as long as you need
Care
An app is never finished: phones update, stores change their rules, libraries publish security fixes and users find the edge case nobody imagined. After launch we look after the product on a monthly plan: fixes, small improvements, upgrades and monitoring, during Indian working hours.
You receive
- A set number of hours each month for fixes and improvements
- Operating-system, store and React Native upgrades on the larger plans
- A clear response time for critical issues on the largest plan
- Honest limits: we don't run a 24/7 on-call desk
You decide
- Which plan fits how fast the product is changing
- What gets built next from the list your users create
The longest example is Flying Pup Films: we looked after its platform from March 2024 to June 2026 and took its backend from 38 security audit findings to none.
What usually goes wrong here, and how we prevent it
Letting a live app drift. Skipped library updates pile up until one forced upgrade breaks everything at once, usually when a store deadline arrives. We take updates in small, regular steps and watch the running costs of maps, messages, storage and AI calls, so neither the code nor the monthly bill surprises you.
What our maintenance plans cover →

Case studies

The method, on real products

Every case study

Pakka Logistics · Bengaluru

Pakka customer app home screen: send a package and choose a service

A delivery network on four surfaces

The problem: A delivery company needed customers, drivers, business shippers and an operations team working from the same live data.
What we did: Customer and driver apps from one React Native codebase, the backend, a business portal with GST invoicing and an operations console, with tracking designed to keep the Maps bill flat.
The result: The first full delivery worked four weeks after we started; everything was in production in under fifteen weeks.

Read the case study

Trainr · Watermelon Inc, Dubai

Trainr app guided workout: logging reps and weight for a set

A fitness marketplace with money in both directions

The problem: Clients book and pay trainers; trainers build programs, chat and get paid out. Every status had to agree across the app and the admin.
What we did: The React Native app for clients and trainers, two backends and the admin console, with payments in and trainer payouts out of the same records.
The result: Live on Google Play, and handed over to the client's own developer with written deploy steps.

Read the case study

ConferBot

One chatbot, every channel

The problem: A chatbot company wanted a bot built once and published everywhere, instead of rebuilt for each messaging app.
What we did: A no-code flow builder on a visual canvas, publishing to a website widget and messaging channels, with every conversation in one shared inbox.
The result: One bot runs on 13 channels, and it is what ConferBot's customers use today.

Read the case study

In our clients' words

What the people we built for say

We had a first delivery working end to end in about a month, from the customer app to the driver app. They also noticed live tracking was running up our Maps bill and fixed it before it turned into a real cost.

Keshav MurthyCMO and Director, Pakka LogisticsSee what we built

Where we work

One studio in Bengaluru, clients across five countries

Bengaluru is our only office. Every project, whether the client is down the road, in the Gulf, in the UK or in North America, is designed, built and supported by the same team here. Since 2021 we have worked with clients in India, the UAE, the UK, Canada and the US.

Registered office

Country Devs LLP (LLPIN ACR-1191)
162/B, 3rd A Cross, 2nd Main Road, Bhuvaneswari Nagar,
Banashankari 3rd Stage, Bengaluru, Karnataka 560085, India

Working across time zones

We work on India Standard Time (UTC+5:30). Our working day overlaps most of a working day in the UAE and the morning in the UK. With clients further west, more of the work happens in writing: plans, test builds and written updates you can review in your own hours, with calls at a time both sides can make.

FAQ

Questions about working with us

What does CountryDevs do, in one sentence?

We design, build and look after mobile apps, web apps, SaaS products and marketplaces, together with the backends and admin consoles behind them, from the first sketch to the app stores and every release after that.

Is CountryDevs a registered company?

Yes. CountryDevs is Country Devs LLP, LLPIN ACR-1191, registered in India with its office at 162/B, 3rd A Cross, 2nd Main Road, Bhuvaneswari Nagar, Banashankari 3rd Stage, Bengaluru 560085. It is our only office.

Do you work with clients outside India?

Yes. Since 2021 we have worked with clients in India, the UAE, the UK, Canada and the US, all from Bengaluru. Our working day overlaps most of a working day in the UAE and the morning in the UK; with clients further west more of the work happens in writing, through plans, test builds and updates you can review in your own hours.

How do I start a project with CountryDevs?

Tell us what you are building on the contact page or on WhatsApp: who it is for, the one journey that must work and when you want to launch. We reply with questions or a call. Most new products then begin with a two-week Discovery Sprint, which produces the scope, user flows, a clickable prototype, the architecture and a milestone plan for the build.

Who will I talk to while my product is being built?

The designers and engineers doing the work. There is no layer of account managers between you and the people who can see the code, so questions are answered by someone who knows the answer and decisions are made in the same conversation.

Does CountryDevs use AI tools to write code?

Yes, for the routine parts of a build, because it makes us faster. It does not decide anything on its own: every change is planned first, read by a senior engineer, covered by tests and recorded against the feature it belongs to before it ships.

Can we hire CountryDevs for only design or only engineering?

Yes. Some clients come to us for brand and UI/UX design and build with their own team; others bring finished designs and need the apps, backend and admin console built. Our design files are prepared for engineers, and our engineers can work from another studio's designs.

Can CountryDevs work alongside our in-house developers?

Yes. We can build one part of the product, such as the mobile apps or the admin console, while your team owns the rest, or start by auditing your existing code for five working days on read-only access so both teams work from the same picture of what is there.

Should our first version be a mobile app or a website?

It depends on how often people will use it and what it needs from the phone. If customers come back weekly, need notifications, live location, the camera or offline use, start with an app. If most visits are one-off, come from search or happen on a desktop at work, start with a web app and add phone apps later. Many of our products have both, sharing one backend, and the Discovery Sprint is where we make this call with you.

What will you need from us during the project?

One person who can make decisions and answer questions within a day or two, access to any systems the product must connect to, and your time at each milestone to use the build and tell us what is wrong. Content such as product text, images and legal terms is yours to provide; we tell you early exactly what is needed and when.

How will I know the project is on track while it is being built?

You will be using it. Test builds go to your phone through Google Play's internal testing and Apple's TestFlight as features land (how a project runs), and each milestone ends in something you can install and check against the plan you approved, not in a status report.

What happens after our app is live?

We keep looking after it on a monthly maintenance plan: fixes, small improvements, operating-system and store updates, and monitoring, during Indian working hours. We are honest about the limits: we don't run a 24/7 on-call desk, and our largest plan sets a response time for critical issues.

We design and build mobile apps, SaaS & marketplaces

Seven kinds of product, and how we build each one