The questions people actually ask us.

There is no price list, because the same-sounding brief can be two weeks or four months of work. What we can do quickly is tell you which band you're in — the ranges on our contact form exist for exactly that, and picking one is genuinely useful rather than a qualification trap.

After a first conversation we scope properly and give you a number before anyone commits. If the honest number is higher than the problem is worth, we'll say so.

A focused internal tool or automation is usually measured in weeks. A product with accounts, billing and a real UI is months, not weeks.

The part people underestimate is the beginning. We spend real time understanding the workflow before writing code — that's the whole method — so early progress looks slower and later progress looks unreasonably fast.

We start where the work happens. For WeDose that meant sitting with around 38 pharmacy owners across Jalandhar, Yamunanagar and Karnal before specifying anything, and it changed the product substantially.

For a client project that might be a day at your counter, on your floor, or beside the person who currently does the job by hand. Then a scoped plan, then build in increments you can see and use, then handover with documentation written for whoever maintains it next.

No. Everything ships with documentation, and the infrastructure is set up so you can run it without us — deploys, backups, and access under your own accounts.

We're happy to stay on for ongoing work, but we build so that you aren't trapped if you'd rather not.

You do. Ownership and licence terms are set out in the engagement's contract rather than being left to assumption, and the default is that what you paid for is yours.

No. WeDose is our own product and it's the clearest example of how we work, not the limit of what we build. The six things listed on our services page — custom software, AI engineering, SaaS platforms, web applications, cloud infrastructure, data and APIs — are what we take on.

What the pharmacy work demonstrates is the type of problem we're good at: regulated, operational, and unglamorous, where the constraints are real and the users aren't software people.

That's the normal starting point, and it's the part we're most useful for. Describe the problem rather than the solution — where the queue backs up, what someone re-types every morning, which number two systems disagree about.

Turning that into a specification is the work, not a prerequisite for it.

Yes, and we have. Sometimes the honest answer is a cheaper off-the-shelf tool, a change of process, or nothing at all.

We'd rather say that than bill for a system that shouldn't exist. It's also how we cut WeDose from a full hospital management system to the pharmacy counter — the evidence said the original ambition was wrong for a team our size.

Yes. We're based in Haryana and most of our field work is in North India, but remote engagements are straightforward — the overlap with Europe is comfortable and workable with the US East Coast.

Mostly TypeScript and Next.js on the front end, Node and Python on the back end, PostgreSQL for data, and AWS or Vercel for hosting. Flutter for mobile, so iOS and Android share one codebase. For AI work: OpenAI and Gemini models, retrieval over your own documents, and vector storage where it earns its place.

We pick from a deliberately small set we know deeply rather than the newest thing, because you'll be living with the choice long after we've moved on.

Usually, yes. A lot of the work is connecting to what already exists — the spreadsheet that became business-critical, the ageing desktop software nobody wants to replace yet, the tool your team refuses to give up.

If we think a rewrite is genuinely cheaper than an integration, we'll show you the reasoning rather than assert it.

Wherever it should for your compliance position. WeDose runs multi-tenant on PostgreSQL with row-level security, hosted in AWS's Mumbai region, aligned to the DPDP Act 2023.

For client work we'll host in your region and under your accounts where that matters, and we'll tell you plainly when a choice has a legal consequence.

Yes — with Flutter, so iOS and Android come out of one codebase rather than two teams and two release cycles.

We will usually ask whether you need one, though. A responsive web app avoids app-store review, forced update cycles, and the people who never get round to installing anything — and for a lot of internal and B2B tools that is genuinely the better answer.

Where an app earns its place — working offline, using the camera or a scanner, push notifications, something staff open every day — Flutter is what we reach for.

The person building it. thinkwarelabs runs as a small technical team rather than an agency — there is no account manager between you and the code, so nothing has to survive a game of telephone on the way to being implemented.

Send us the problem through the contact form or straight to hello@thinkwarelabs.com. A few sentences about what's going wrong is more useful than a formal brief.

We read every serious enquiry and usually reply within a day.