A first version of a product exists to answer a question: will people use this, and will they pay for it. The reliable way to answer it is the smallest version that tests the idea end to end, for real users with real data. Where one of our own platforms is close to what you need, we start from it, so sign-in, roles, payments and admin screens already work and the budget goes into the part of the product that is new. You receive the system and its source code.
Who this is for
- A new product that has to meet real users. Founders and product teams with an idea to test, who need an MVP that works rather than a demo that stops at the first click.
- A service you run internally, turned into a product. A process your organisation already does well, which other organisations would pay to use.
- A business close to one of our platforms. A learning portal, a restaurant, a hotel, a sports venue or a ticket desk. If the platform as it stands covers most of it, that is platform implementation rather than a new product.
- An agency that wants a platform for its own market. That is a partnership, set out on our partners page.
What you get from a product build
- A working first version, deployed for real users rather than stopping at a demo
- The admin and operations screens your team needs to run it
- Analytics wired to the question the first version has to answer
- Architecture kept open where the product is most likely to change
- The system and its source code, including any platform code underneath it
- A written list of what was left out, and why, to start the next version from
What a product build starts from The platform layer already runs in production; the budget goes into the layer above it
What we build for your product The path that tests your idea, your rules, your screens and your integrations
Built on
Accounts and roles Sign-in, permissions, audit trail
Payments Gateways and orders
Admin Back-office screens, exports, notifications
Runs on
Drupal Open-source core, on hosting you choose
An engineer reads it and replies within one business day.
How a product build runs
The scope has to earn its place. We work the idea down to the smallest version that tests it, put a working prototype in front of you before anything is signed, and build only what the first real users need.
How a software product build runs
- Discovery The question the first version must answer, and the one path through the product that answers it. Output: the scope sheet
- Prototype That path working on real data, often on the platform closest to your product, before you sign. Output: the prototype
- Fixed price Quoted against the version that tests the idea, not the product you eventually want. You keep the priced scope
- Build Features shown working on staging as they land, with the admin tooling built alongside. You keep the repository
- Acceptance The first users' path tested end to end, and the analytics checked, before launch. You keep the test record
- Warranty Defects in what we built are fixed by the team that built it, while you learn from the first users. You keep the handover pack
Starting from a platform instead of an empty repository
Every product needs the same unglamorous machinery: accounts and sessions, roles and permissions, an admin interface somebody can operate, audit trails, notifications, payments and exports. None of it sets the product apart, and all of it has to work before the first user arrives. We have built and run that machinery in our own platforms, each in production today, so a product build usually starts from the closest one.
Starting from our work does not make you a tenant of ours: you receive the whole system and its source code, and you can host it anywhere and hire anyone to continue it. More platforms are on the way; the current list is on our products page.
What belongs in the MVP
The hard part of a first version is deciding what to leave out, and it feels like risk. It is the opposite: every feature added before the idea is tested has to be maintained whether or not it turns out to matter.
- In: The one path that proves the idea, end to end, for a real user with real data; the admin tooling the team needs to operate it; enough analytics to answer the question you are testing.
- Out, usually: Settings screens, second user roles, bulk operations, an API nobody has asked for, and every feature justified by a customer who does not exist yet.
- Deliberately open: The places the product is most likely to change. We keep those loosely coupled and name them, so the second version is an extension rather than a rewrite.
We will argue for cutting scope. If you overrule us, we build what you asked for and say what it costs, because that decision is yours.
What a product build costs
Scope is fixed against the version that tests the idea, not against the product you eventually want, so the first number stays small. Later versions are quoted as their own pieces of work once the first one has taught you something. Where the build starts from one of our platforms, you pay for the part that is yours, not for rebuilding what already runs.
The band depends on what the first version must do: rules, search and two-way traffic with other systems put it in Large; a product that lives behind a login, with roles deciding what each person reaches, sits in Secure Portal / Intranet. What each includes is on the pricing page.
Work we have delivered
The full case studies behind the screenshots on this page.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
Can we start from one of your platforms?
Often. EverLMS, MenuNerds, MineRooms, MineCourt and MineTickets are each in production, and starting from the closest one means customising rather than starting at zero. If none is close, we build from Drupal core instead and say so at the start.
Do we receive the source code if we build on your platform?
Yes. You receive the whole system and its source code, including the platform code underneath, and you can host it anywhere. The wording is in our FAQ on source code.
How small should the first version be?
Smaller than feels comfortable. Every feature added before the idea is tested has to be maintained whether or not it turns out to matter. We will argue for cutting, and build what you decide.
What if the idea changes after launch?
It generally does. The architecture is kept open where change is most likely, which is most of what separates a first version that can grow from one that has to be replaced.
Do you take equity instead of fees?
Not by default: product work is priced as work, at a fixed price for an agreed scope. The exception is our 10% programme. There you pay a tenth of the development price, and we invest the rest in the project in exchange for a minority stake, worked out by a formula agreed before the build starts. The programme's own page explains who it suits and how the share is calculated.
Can the product have a mobile app?
Everything we build is responsive, and for most products that is enough. Where a native app is warranted, for offline use, push notifications or hardware the browser cannot reach, it is built against the same back end as part of the product, not as separate work. See our FAQ on mobile apps.
Not covered here? Ask us directly.
Describe the productAn engineer reads it and replies within one business day.
Build
Related services
- Custom Drupal Development
- Enterprise Website Development
- Custom Web Application Development
- Drupal Intranet and Portal Development
- Drupal Website Redesign and Theme Rebuild
- Drupal Multisite and Site Families
- Drupal Commerce Development
- Headless and Decoupled Drupal
- Drupal Module Development and Porting
- UI/UX Design for Web Platforms
- AI Development for Drupal and Web Platforms
- Outsource Drupal Development
Tell us what you are trying to find out
A first version exists to answer a question. Tell us which question, and we will work out the smallest thing that answers it.
An engineer reads it and replies within one business day.