App development · Amsterdam
App development company in Amsterdam.
QalbIT is an IT company building mobile apps, websites and custom software for Amsterdam businesses from Ahmedabad, India: scale-ups shipping a first app alongside a product they already sell, retailers and agencies who need a site that converts, and operations teams ready to replace a workbook with a real system. There is no QalbIT office in Amsterdam and no Netherlands entity, and this page sets out exactly what that changes.
Amsterdam is where a remote partner loses the least to the clock of any market we serve. The Netherlands sits 3.5 to 4.5 hours behind Ahmedabad, so your working day falls entirely inside ours. The rest of this page covers what that is worth in practice, GDPR, and the cases where a local agency is honestly the better hire.
2018
Building software since
120+
Projects delivered
3.5–4.5h
Time difference, Ahmedabad to Amsterdam
4.9
Google rating, 18 reviews
Get your free estimate
Three quick questions: scope, approach and a price range back within 48 hours. No sales call required first.
Definition
What app development in Amsterdam means when the developers are not in Amsterdam
App development in Amsterdam means designing, building and shipping a mobile app, and usually the website and back office around it, shaped to one company’s product. QalbIT does that work as a remote engineering partner from Ahmedabad, India, with a time difference small enough that a Dutch working day falls entirely inside ours, and with no office in Amsterdam.
The engineering does not change with where the developers sit. The clock, the contract and the data rules do, and in Amsterdam most of that works in a remote partner’s favour.
An agency registered with the Kamer van Koophandel is inside your own legal system: someone can visit your office, the invoice carries Dutch VAT, and procurement recognises the supplier without a second look. A partner outside the country earns that confidence on paper instead: a written scope, a data protection position your compliance contact has reviewed, and a working window that covers most of your day.
None of that is unusual, and it is far cheaper to settle before a contract than after a security review.
We are the remote option. We would rather set that out here than have it come up in month three.
At a glance
Core focus
Mobile apps, websites, custom software and integrations
Engagements
A first app · a website rebuild · custom back-office software · a standing engineering pod
Delivery
Remote from Ahmedabad; your working day overlaps ours by 3.5 to 4.5 hours, every day of the week
Amsterdam position
No office, no staff, no Netherlands entity
Ownership
Repositories, cloud accounts and IP in your name, assigned as the work is created
Definition
Amsterdam agency, freelance developer, or remote engineering partner
Three purchases that get compared on price when they are not the same purchase.
Amsterdam agency
A company registered with the Chamber of Commerce, on Dutch hours all day, able to meet in person. You are buying proximity and a domestic contract. Best when the work needs frequent workshops or runs through procurement that expects a local supplier.
Freelance developer
One person billed by the day or the hour into a process you already run. You are buying capacity; architecture, testing and release stay with you. Best when you already have someone technical directing the work.
Remote engineering partner
A small senior team that owns a defined build end to end and hands over the repository when it is done. There is no Dutch entity, so the contract and data protection are settled properly at the start. Best when you know what the product must do and want it built well the first time.
We are the third of those. Where one of the first two is the better fit, we say so on the first call, not after a deposit.
Fit
When a remote partner is the right call for an Amsterdam company, and when it is not
Both sides of this, in the open.
Hire a remote partner when
- You can describe what the app or system has to do, and someone on your side can decide without a long approval chain.
- The work is a defined build, such as a first app, a website rebuild or a back-office system, rather than an open-ended programme.
- A few hours of live contact a day is enough, with the rest running on a written handover.
- You want the source code, the app store listing and the documentation in your own accounts when it ships.
- Personal data is in scope in the ordinary way, and your compliance contact is willing to review our evidence against your rules.
Hire locally instead when
- A client contract or a procurement rule requires a supplier established in the Netherlands or the EU.
- The project needs people on site regularly: a retail fit-out, a trade-show build, a filmed shoot.
- Your security policy forbids any access to production data from outside the EU and masked data will not do.
- Delivery has to run inside Dutch office hours only, with no written handover accepted.
- What you actually need is a contractor under your own product lead, in which case a freelancer costs less to manage.
What that looks like for an Amsterdam buyer
Amsterdam is a city of scale-ups that already work with distributed teams, so a remote partner is a familiar shape here rather than an unusual one. The parts of the engagement that a careful buyer checks are the same ones we settle before the build: where data sits, who can reach it, how a release is approved, and what evidence exists if something goes wrong. We would rather hand that over in writing than promise it in a pitch. We turn down Amsterdam projects that belong in the second list. A remote build where a local agency was the right answer costs more than the fee, and it shows within a few weeks.
Next step
Not sure which list you are on?
Send us what you are building, what data it will hold and what your procurement rules say. We will tell you honestly which list you belong in, including when a local agency is the better call.
Comparison
Remote partner vs an Amsterdam agency vs a freelance developer
Every row below is a real difference, including the ones we lose. There is no day-rate row: we have no sourced figure for what Amsterdam agencies or freelancers charge, and inventing one would be worse than leaving it blank. We will run this against your actual product, your data and your procurement rules rather than the generic case.
| Amsterdam agency | Freelance developer | QalbIT (remote partner) | |
|---|---|---|---|
| Can meet in person | Yes | Often | No |
| Live hours on Dutch time | Full working day | Full working day, usually | 3.5 to 4.5 hours behind, inside your whole working day |
| Who owns the architecture | The agency | You do | We do, reviewed with your technical lead |
| Who owns testing and release | The agency | You do | We do, with your sign-off as the gate |
| Contract and currency | Domestic, EUR | Domestic, EUR | Your contract, invoiced in EUR or USD as agreed |
| Source code and IP | Varies by contract | Yours | Yours, assigned as the work is created |
| Security and due-diligence questionnaires | Routine | Rare | Completed by us, on request |
| Contracts requiring an EU-established supplier | Eligible | Depends on registration | Not eligible |
| Team continuity | Moves with agency workload | One person, availability varies | Small, senior, named in the proposal and unchanged |
01
The "No" and "Not eligible" rows are deliberate.
A table where one column wins everything is a brochure. The rows above are honest reasons to hire someone else, and better found here than partway through a contract.
02
Hosting and engineering location are separate questions.
Your app or platform can run on infrastructure in an EU region, under your own account, while the engineers writing it sit elsewhere.
03
A freelancer adds hands, not a system.
A single contractor is capacity for a process you already run. Without someone on your side owning architecture and release quality, that capacity produces code faster than it produces a working product.
04
Contract eligibility is binary.
If a client contract requires an EU-established supplier, engineering quality does not substitute for it. Ask us on the first call and the answer comes back the same day.
What we build
What we build for Amsterdam companies
Mobile apps, websites and the custom software behind them, built as one connected system rather than three separate vendors who do not talk to each other.
Mobile
Mobile apps for iOS and Android
One Flutter codebase for both platforms, built for a consumer product, a booking flow or an internal tool used away from a desk.
Websites
Websites that convert
A fast, well-structured website in Next.js or WordPress depending on what the business needs, built to load quickly and to be easy for your own team to edit afterwards.
Platforms
Custom software and operations platforms
Back-office systems that replace a spreadsheet and a shared inbox with roles, approvals and a history of who did what.
SaaS
SaaS products and MVPs
Multi-tenant products with billing, roles and usage limits, shaped for a founding team that needs paying customers before the next funding round.
Integrations
APIs and integration engineering
Wiring a payment provider, a CRM or a warehouse system to the tools around it, with queues and retries so a failed message is visible rather than silent.
Cloud
Cloud environments and delivery pipelines
AWS accounts in your name, in an EU region, infrastructure as code and staged releases, with the access logs a due-diligence review will ask you to produce.
Cost
How much does app and software development cost in Amsterdam?
An app or a custom platform for an Amsterdam company is priced on scope, platform count and integration count, not on headcount. At QalbIT, fixed-scope projects start from $6,500, dedicated engineers from $3,200 per engineer per month, and a scoped MVP or app typically from $5,000. A written scope with the exclusions named comes back within 48 hours of the first call, and a first release usually lands 6 to 14 weeks after that scope is signed.
Those are our own floors, and the only figures on this page about what software costs. Search the question and you will find ranges a long way apart, published with nothing behind them. We are not adding to that.
We do not publish what an Amsterdam agency or a freelancer charges either, because we have no figure we could attribute to anyone. Send the same written scope to three suppliers and you will learn more than any page can tell you.
What we do instead is scope first: a discovery call, a written scope with the exclusions listed, then a fixed price for phase one before you commit to anything beyond discovery.
Try the software development cost calculatorWhat moves the number
Scope of the first release
The largest single driver. One feature built properly beats four built thinly, and it makes the second phase easier to justify.
Platform count
A web app alone, a single mobile platform, or web plus iOS and Android with offline sync: each step adds build, test and release work.
Integration count and quality
A documented REST API with OAuth is quick. A payment provider or a legacy system with a manual export needs more time.
Data protection evidence
Consent handling, retention rules and deletion that reaches backups are engineering work with their own timeline.
Roles and approval rules
Two user types is a data model. Several roles with delegated permissions is closer to a system in its own right.
Design depth
A functional interface is one estimate; a fully designed brand experience with animation and edge-case states is another.
How we work with Amsterdam teams
A delivery process built around a 3.5 to 4.5 hour offset
The Netherlands sits behind Ahmedabad, not ahead of it, so your working day falls inside ours rather than only a slice of it.
Discovery and written scope
One call about the product, who it is for and what it has to do first, then a written scope with the exclusions named. The document is yours whether or not you hire us.
A scope, a first-phase price range and the name of the engineer who would lead it.
48 hours
Prototype and architecture
A clickable prototype in week one, so you can react to real screens rather than a document. Alongside it: data model, access control and hosting region, agreed before anyone opens an editor.
Approved screens and an architecture your technical lead has seen.
1–2 weeks
Build in fortnightly slices
Working software demoed every two weeks, checked against the scope while you watch.
Working modules proven against real use, and a backlog shaped as you went.
6–14 weeks, scope-dependent
Harden, then release
Permissions, load behaviour, backups, monitoring and a tested rollback are signed off before launch, and app store submissions are prepared where relevant.
A release you can ship with confidence, evidence attached rather than promised.
2–3 weeks
Run and extend
Monitoring, a support window matched to your day, and the next slice of roadmap chosen from what people actually use.
A product that keeps earning its place, and a team that can hand it to yours whenever you want it.
Monthly, 30 days notice
Amsterdam runs CET in winter and CEST in summer; Ahmedabad stays fixed at UTC+5:30. That is a 3.5 to 4.5 hour offset, small enough that your entire working day sits inside ours. A written handover closes anything left over at the end of your day.
Book a scoping callWhere we fit best
Amsterdam projects we take on
These are the engagements that work well from a distance. The ones that do not are listed higher up the page, and we mean that list.
First app
Shipping a first mobile app alongside an existing product
A companion app for a product a scale-up already sells on the web, built to the same standard as the product itself rather than as an afterthought. For scale-ups and growing product teams.
Website
Replacing a template site that has stopped converting
A website rebuilt with a real content structure, faster load times and analytics that actually inform the next decision. For retailers, agencies and service businesses.
Compliance
Bringing an existing app or platform up to GDPR properly
Adding consent handling, retention enforcement and deletion that reaches backups to a product built before anyone asked for them. For teams facing a review or a new compliance contact.
Extension
Building the back office behind a consumer product
Admin tools, reporting and integrations that a customer never sees but a team relies on every day. For companies whose product outgrew its spreadsheet.
Industries
Sectors we build for in Amsterdam
Software is shaped by the business it runs. These are the Amsterdam sectors we have already built for, and where the process questions are familiar.
Fintech and payments scale-ups
Onboarding flows, dashboards and integrations for teams building on top of a payments or banking licence, with card data kept out of the codebase by tokenising at the processor.
E-commerce and retail brands
Storefronts, order management and stock integrations for brands selling across the EU, connected to the couriers and marketplaces they already use.
Travel, hospitality and tourism
Booking flows, itinerary tools and partner portals for the travel and hospitality companies based in a city that runs on visitors year round.
Media and creative agencies
Client portals, asset management and campaign tooling for the agencies and studios operating out of Amsterdam for clients across Europe.
Professional services
Client and case management, reporting and document workflows for consultancies and professional-services firms replacing email threads with a system.
Logistics and trade
Shipment tracking, supplier portals and warehouse integrations for the trading and logistics companies the city’s port and airport connections support.
If your sector is not on that list, the question we ask first is the same one: what does a day of this work look like, and where does it break?
Next step
An off-the-shelf app or template rarely fits a growing business for long.
That is usually what starts a custom build. Describe what the packaged tool cannot do and we will tell you whether it justifies a project, or whether configuring what you already have would do.
EU compliance
Building apps and software for Amsterdam: GDPR and app-store rules
These are the obligations that shape how an app or platform is built for a Netherlands company, and the questions a supplier outside the EU has to answer before you sign anything. We are engineers rather than your lawyers: this is what we build, not legal advice about what applies to you.
EU GDPR and the Dutch implementation act
Any Amsterdam system holding personal data sits under the EU General Data Protection Regulation, in force since 25 May 2018, and the Dutch implementation act, the Uitvoeringswet AVG, enforced by the Autoriteit Persoonsgegevens. The rights of access, rectification, erasure, restriction and portability, and the principles of data minimisation and storage limitation, are the ones that reach the code. For an app that means consent handling built into onboarding rather than bolted on, retention rules the system enforces rather than a policy that describes them, and deletion that reaches backups and analytics exports as well as the primary database. Whether a data protection impact assessment is needed, and how data leaving the EU is handled, are decisions for your own compliance function. We build the machinery that lets you honour the decisions they make. Sources: Regulation (EU) 2016/679 (GDPR) · Uitvoeringswet AVG · Autoriteit Persoonsgegevens.
Personal data
App Store and Google Play data disclosure
A published app has to declare what data it collects and why, through Apple’s App Privacy details and Google Play’s Data safety section. Getting that declaration right depends on how the app is actually built, so we design the data flows and the third-party SDKs in from the start rather than reverse-engineering a disclosure after the app is finished. The submitted declaration is the publisher’s responsibility. We provide an accurate technical account of what the app collects and sends, and you or your legal team sign it off. Sources: Apple App Store Review Guidelines · Google Play Data safety requirements.
Mobile apps
PCI DSS, kept out of your code
The cheapest way to handle card data is to never hold it. We tokenise at the payment provider, so your app or platform stores a token, the last four digits and a brand rather than a primary account number, which keeps the bulk of PCI DSS scope out of the code we write. Your PCI obligations remain yours, and the right self-assessment questionnaire depends on how you take payments. Sources: PCI DSS v4.0.1 · PCI Security Standards Council.
Payments
We build products that produce this evidence natively rather than bolting compliance onto software that resists it. Where a launch date or an audit is driving your timeline, that date is where we plan backwards from.
Working with us
Hiring a vendor outside the Netherlands: the honest version
Your finance, legal and security contacts will each have a short list of questions about a supplier outside the country. Here is ours, with the answers.
The contract
We sign your contract with the jurisdiction, liability and termination clauses your legal team prefers. We do not ask clients to contract under the law of another country, and we do not run engagements on an exchange of emails.
Governing law
Currency and invoicing
Invoices are raised in euros or US dollars, as agreed in the contract, against the milestones or the monthly rate written into it. VAT treatment of a non-EU supplier is a matter for your accountant; we supply whatever details your finance team needs.
EUR or USD
Intellectual property
Code, designs, documentation and infrastructure definitions are assigned to you as they are created, not on final payment. Repositories, app store accounts and domains are opened in your name from the first commit.
Assignment
Confidentiality
An NDA is in place before you share anything sensitive. Use yours or ours, mutual is the normal case. Nothing about your project is used as a reference without your written agreement.
NDA
Insurance and security questionnaires
Certificates of insurance are provided on request. Security questionnaires are completed by the people who would do the work, not by a sales team.
Vendor risk
No local entity, and what that rules out
QalbIT has no Netherlands entity, no Amsterdam office and nobody who can be in your building next week. Where a client contract requires an EU-established supplier or work performed inside the Netherlands, we are not eligible, and you will hear that on the first call rather than after a proposal.
The limit
None of that is a reason to avoid a remote partner. It is a reason to handle the paperwork properly at the start instead of assuming it away.
Tech stack
Technology we use for Amsterdam builds
Apps and platforms live for years after launch, so we choose technology a new engineer can read in an afternoon and your future team can maintain without us.
Backend and business logic
- Laravel (PHP 8) and Node.js for APIs and business rules.
- NestJS where integrations and event-driven flows dominate.
- Queues, schedulers and retries for notifications and syncs.
Interface and mobile
- Next.js and React, server-rendered where search traffic matters.
- Flutter for one mobile codebase across iOS and Android.
- Analytics wired in from the first release, not added afterwards.
Data and integrations
- PostgreSQL and MySQL with constraints that protect data integrity.
- REST and GraphQL integrations with payment and logistics providers.
- Event pipelines for apps with real-time or notification needs.
Security and delivery
- AWS accounts in your name, in an EU region, defined in Terraform.
- Least-privilege access, logged, with break-glass reviewed after use.
- Staged releases through GitHub Actions, every one reversible.
Already running something that works? We extend it and put in writing, before any code is written, which parts should be left exactly where they are.
Outcomes
What the project should actually change
Not projections. These are the changes the build is meant to produce, and how you would know whether yours did.
| What changes | How you would measure it |
|---|---|
| A published app that people actually keep using | Retention past the first week, tracked from launch |
| A website that converts rather than just exists | Conversion rate before and after launch |
| Work moves without being retyped | Hand-offs that still require a person to copy a value |
| Data requests are answered from the system | Hours to produce an access or deletion response |
| Releases ship without a rollback scare | Incidents traced back to a release, per quarter |
| The team sees position without asking anyone | Time from question to answer |
A note on sourcing
A note on sourcing
We do not quote market figures on this page: not Amsterdam salary bands, not agency day rates, not app-store benchmark statistics that circulate without a primary source. The only numbers here are our own, and each one names where it comes from.
Why QalbIT
Why Amsterdam companies keep us on the project
Building this kind of software since 2018
120+ engagements delivered for 50+ clients since 2018, across web, mobile and platform work. Clutch 5.0 from 8 reviews, Google 4.9 from 18 reviews, and 100% job success on Upwork.
The smallest time difference we work across
A 3.5 to 4.5 hour offset means your entire working day is live time with the people writing the code, not a queue of tickets answered overnight.
We say what we are
No Amsterdam office, no Dutch staff, no Netherlands entity and no implied presence anywhere on this site. The compliance and paperwork sections exist because we would rather lose a deal at the scoping call than at a supplier review.
The named engineers are the ones who build it
Whoever appears in the proposal writes the code. No part of your build is handed to another firm, and nobody is quietly swapped mid-sprint to cover another account.
We will tell you to hire locally
When an Amsterdam agency is genuinely the better answer, you hear it on the first call. It costs us a project and saves you a year.
QalbIT did a great job turning my idea into a real product. What I really appreciate is how well they understand my requirements, even when I'm not fully sure how to explain or finalize things. They listen patiently, guide me when I'm stuck, and always try to find the right solution. I really enjoy working with their team and I'm definitely looking forward to continuing our work together in the future.
FAQs · App development in Amsterdam
Questions Amsterdam teams ask before they start
Overlap hours, budgets, GDPR, paperwork and who owns what, answered the way we would answer them on a call.
Talk to the teamNext step
Let us scope the first release.
Tell us what the app or system has to do, who it is for, and which date is fixed. We will map it, name what earns its place first, and put an honest price range against a phased plan. If an Amsterdam agency is the better answer, that is what the reply will say. A written scope with the exclusions listed comes back within 48 hours, yours to keep either way.