Question 1

What does a project at Vulpo cost?

Accepted Answer

Our projects range from two-week proof-of-concepts to multi-month platform builds. Pricing depends on scope, complexity, integrations required, and timeline expectations. There is no honest single answer to "what does software cost", a customer portal for a Belgian mid-market company is a different investment than an EU-wide platform with real-time integrations. For smaller, well-defined projects, we work with fixed pricing so you have full certainty about the total cost. For larger projects where scope evolves during the build, we work on a time-and-materials basis with weekly reporting, so you always know where the budget stands. We never send open-ended invoices without prior conversation. The best way to get a realistic picture: schedule an exploratory conversation with us. In about 45 minutes, we understand your situation well enough to sketch an indicative range and suggest the right project format. That range is typically in your inbox within 3 to 5 business days after our conversation.

Question 2

Do you work with clients outside Belgium?

Accepted Answer

Bert De Swaef regularly speaks at international Laravel conferences (Laracon EU, Laracon India), and our team is used to international collaboration. Working across borders isn't an exception for us. It's a regular part of how we operate. We work pragmatically. For clients in the UK, Germany, France, Scandinavia, or the Benelux, collaboration is usually smooth: similar time zones, comparable business culture, and mature markets that understand the value of custom software. Communication happens in English or Dutch depending on the client's preference. For clients in Asia or the Americas, we make an individual assessment based on time-zone practicalities and working rhythm. Some projects work fine asynchronously, for example ones with clear specifications and defined milestones. Others need a lot of synchronous communication (daily standups, real-time design decisions), and that's harder across an 8-hour gap. We're honest about this upfront rather than committing to a working arrangement that will cause friction later. Regardless of where you're based, our approach to communication stays the same: weekly demos, transparent reporting, and a single point of contact who knows your project inside out.

Question 3

Do you work with fixed pricing or time-and-materials?

Accepted Answer

Fixed pricing gives you certainty, but it requires scope to be crystal clear upfront. It works well for projects where we can accurately estimate the effort, for example, a Two-Week POC Sprint, a redesign of an existing system, or a well-scoped integration. Time-and-materials gives flexibility for projects where scope evolves during the build. This is often the case for innovative projects, custom software that touches multiple business processes, or platforms being built for a market that is still shaping itself. With time-and-materials, we always work with an estimated range and weekly reporting: you receive a status update every week with hours spent, work delivered, and expected work ahead. Before we start, we determine together which approach best fits your project. It's not uncommon that a single project starts on time-and-materials (exploration phase) and switches to fixed pricing once scope is clear (build phase). What matters most is that both parties know how the numbers work at any given moment. We don't like surprises any more than you do.

Question 4

How do you handle data ownership, hosting, and GDPR compliance?

Accepted Answer

Data ownership is straightforward: everything your platform stores about your business and your customers belongs to you. We host the infrastructure that runs your software, but you're the data controller in every sense. For most projects we host in Europe, typically Google Cloud with data centres in Belgium, the Netherlands, or Germany. This means GDPR compliance by default. Data doesn't leave the EU unless there's a specific reason and legal basis, in which case we discuss it with you upfront. For sensitive sectors like healthcare, finance, government, or education, we add extra measures based on what the sector requires. This can include data encryption at rest and in transit, segregated environments per client, audit logging, role-based access controls, and detailed incident response procedures. If your organisation has a DPO or security officer, we work directly with them to match our setup to your compliance requirements. At project delivery, you get a technical dossier documenting infrastructure choices, security measures, and data flows. Your DPO or security team can review it. It's meant to make their job easier, not to be a marketing document. We don't process your customers' personal data ourselves. We build the systems that do, and you remain the data controller with full authority over how that data is handled.

Question 5

Who owns the code you write?

Accepted Answer

Intellectual property is arranged per project, in writing, before we start. It's not a footnote. It's part of the project agreement, and we make sure both sides know exactly what belongs to whom before any code gets written.

For most of our work, you get full rights to the custom code built specifically for your project. That includes your business logic, your data models, your workflows, your user interfaces. You receive source code, documentation, and access credentials at delivery.

For reusable libraries or frameworks we built before or outside your project, we work with licenses that give you unrestricted use. We keep these in our own library so we can reuse them for other clients, but within your project you can use them freely.

For third-party components, things like AI APIs from OpenAI or Gemini, payment providers like Mollie, or open-source libraries, their own license terms apply. We walk you through these upfront so you know what depends on what.

We deliberately avoid vendor lock-in. If you ever want to work with another party, everything you need to make the switch is there. No client has ever left us for another agency, but we've built things so it wouldn't be a problem if one did.

Question 6

How long does an average project take?

Accepted Answer

Timeline depends on scope, complexity, and how much clarity there is at the start. We always communicate realistic timelines, no false promises of "live within a month" when that isn't feasible. For shorter projects, we offer our Two-Week POC Sprint: within two weeks we build a working version of your idea with a fixed price, deadline, and scope. This works well for validating an idea before committing to a larger investment. For mid-sized platforms, a customer portal, an internal workflow tool, a back-office system, timelines typically run 8 to 16 weeks. We work in sprints of 1 to 2 weeks with weekly demo moments where you see progress firsthand. You're never left waiting three months for a first delivery. For larger projects with AI integration, complex data migration, or multi-system integration, timelines can extend to 4 to 6 months. In those cases we always break the work into phases, so you receive working software throughout the project instead of at the very end.

Question 7

What happens if one of your developers leaves during the project?

Accepted Answer

In fourteen years at Vulpo, we've never interrupted a project because of staff changes. Continuity is an operational priority, not a promise. Every architectural decision on a project gets documented in writing, so anyone joining the project understands not just what was built, but why. Code goes through peer review before it's merged. At least two team members understand every part of the codebase. When one developer is on holiday, another can pick up their work without a briefing that lasts days. We also make sure clients have direct access to their project's technical documentation, repository, and deployment infrastructure. If for any reason we disappeared tomorrow (which we won't, but the principle matters), another development team could pick up where we left off. This isn't a nice-to-have. It's how we structure work from day one. For you, this means you're never dependent on one person. You work with Vulpo as an organisation, and the value of that organisation is precisely that individual availability doesn't determine project outcomes.

Question 8

How are you different from a freelancer?

Accepted Answer

A freelancer can deliver excellent work, usually at a lower hourly rate. That's a real trade-off, and we don't pretend otherwise. For smaller projects or clearly defined tasks, a specific feature, a limited integration, a short-term consulting engagement, a freelancer can be exactly the right choice. Where we make the difference is on projects your business needs to rely on. We've been around for fourteen years and will still be here five years from now. When something goes wrong, there's an organisation behind your project, not one person whose availability depends on their personal circumstances. When a project needs multiple areas of expertise, backend architecture, frontend interaction, DevOps infrastructure, AI integration, you get those specialists in the same room. We work with clearly defined agreements, structured project management, and post-launch support that doesn't stop the moment the invoice is paid. For enterprises and mid-market companies making significant software investments, that structural reliability tends to matter more than the hourly rate. We also regularly work with freelancers when a project calls for it: a specific design challenge, a niche technical skill, extra capacity during busy periods. It's not always agency versus freelancer. Sometimes it's both.

Question 9

Can we start with a small proof-of-concept

Accepted Answer

We often recommend this before larger projects. Instead of committing to an investment based on a document that describes what the software should do, you commit to two weeks of focused work that produces something you can actually see, click, and evaluate. At the end of the sprint, one of two things is true. Either you have a working prototype you can build on, and we have concrete insight into what the full build will require (often reducing overall project risk by 40-60%. Or we've both discovered together that a larger project isn't the right route: maybe the assumptions were wrong, maybe the market wasn't ready, maybe a different solution altogether makes more sense. Both outcomes are valuable, and both are cheaper than discovering them after months of building. We ask for ashort intake beforehand to determine whether your idea is suited for this approach. some projects needs more strategic clarity before we can build. For example, when the target user hasn't been defined yet, or when the key business decisions are still open. In those cases, we recommend a shorter strategic session first, and a POC sprint later once things are clearer. Get in touch for an intake conversation, and we'll discuss whether a POC sprint fits your situation, along with exact scope and pricing.

Who owns the code you write?

Still have a question?

Other questions