Why don't you publish fixed prices?

Because a published figure would be wrong for almost everyone who read it. The same feature can differ severalfold in cost depending on the systems it must integrate with, the state of your data and the compliance obligations you carry. Quoting a number before understanding those factors produces estimates that get revised — which is exactly what clients dislike most.

Do you charge fixed-price or hourly?

Fixed-scope by default. We define the scope precisely, then commit to a price and timeline against it, with changes handled through a written change request. For ongoing product work where priorities shift each sprint, a dedicated-team arrangement usually serves you better, and we will say so.

How long does a project take?

A prototype typically takes weeks; an MVP typically takes a few months; a full production platform takes longer and is delivered incrementally rather than in one release. We work in two-week sprints, so you see working software throughout rather than waiting for a single delivery date.

What do I need before requesting an estimate?

Less than most people assume. A description of the problem, who it is for, any systems it must connect to, and your rough timeline is enough to start. If requirements are genuinely unclear, we will recommend a short paid discovery engagement rather than guessing at a number.

Can we start small and expand later?

Yes, and for most clients that is the right approach. Starting with a prototype or narrow MVP gets something real in front of users quickly, and what you learn from that usually changes the roadmap. We architect early work so it extends rather than needing to be rebuilt.

Yes. You own the code and the infrastructure, and we hand over full documentation at launch. There is no proprietary platform lock-in and no requirement to keep us on retainer to keep your product running.

What happens if the scope changes mid-project?

Scope changes are normal on any real project. We handle them with a written change request setting out the impact on cost and timeline before any work starts, so the number never moves without your agreement.

Pricing & engagement

What actually drives the cost of your project

We don’t publish rate cards, because a number quoted before we understand your scope would be wrong for almost everyone who read it. What we can do is show you exactly which factors move the estimate — so that when we do quote, you can tell whether it’s fair.

Send us your scope

What moves the number

Eight factors that decide what a project costs

Roughly in the order they tend to matter. Two projects with identical feature lists can differ severalfold on these alone.

Scope and feature depth

The single largest driver. Ten screens with simple CRUD cost a fraction of three screens with real-time collaboration, permissions and audit trails. Depth matters far more than page count, which is why counting screens is a poor way to estimate.

Integrations with systems you already run

Connecting to a documented, modern API is routine. Connecting to a legacy ERP, an undocumented internal database or a payment provider with strict compliance rules is not. Integration count and integration quality are different questions, and the second one usually decides the estimate.

Data readiness

Especially for AI work. If your data is clean, labelled and accessible, model work starts immediately. If it lives across spreadsheets, PDFs and a CRM nobody has audited in three years, the preparation is the project. We assess this before quoting, because getting it wrong is the most common reason estimates move.

Compliance, security and regulatory load

Handling health records, financial data or personal information under the NZ Privacy Act or GDPR adds architecture, testing and documentation work that a marketing site never needs. This is scope, not overhead.

Design maturity

An existing design system with defined components is the cheapest starting point. A rough idea needs research, wireframes and iteration first. Neither is wrong — but they are different projects, and treating them as the same is how quotes get revised.

Expected scale and reliability

An internal tool for forty staff and a consumer product expecting forty thousand concurrent users share almost no architecture. Building day-one infrastructure for scale you will not reach for two years is a common and expensive mistake, so we size deliberately.

Timeline pressure

Compressing a schedule means more people working in parallel, which costs more per unit of output, not less. A hard external deadline is a legitimate reason to do it — we will tell you plainly when it is not worth the premium.

What happens after launch

Software is not finished at launch. Hosting, monitoring, model or dependency updates, security patching and support are ongoing. We separate these from build cost so you can see the real total, rather than discovering it later.

Project complexity

Four kinds of build, and when each is right

Prototype / proof of concept

Prove one risky assumption before committing budget.

A single core workflow, minimal design polish, sample rather than production data, no scaling requirement. Built to be shown, tested and often thrown away.

Best when: You need to validate demand, test feasibility, or show something concrete to a stakeholder or investor.

MVP — first production release

Put a real product in front of real users and learn from it.

The smallest coherent product a customer would genuinely pay for: core workflows, authentication, payments if needed, production infrastructure and monitoring. Deliberately narrow, deliberately real.

Best when: The concept is validated and you need to reach the market and start compounding learning.

Full production platform

Support a business that is already operating on the product.

Multiple user roles, third-party integrations, admin tooling, analytics, hardened security, tested scaling and a proper release process.

Best when: You have traction and the current system is the constraint on growth.

Enterprise / regulated build

Operate reliably under external obligation.

Compliance requirements, audit trails, SSO, formal QA, penetration testing, documented handover, defined support commitments.

Best when: You sell to enterprise customers, operate in a regulated sector, or carry contractual reliability obligations.

Engagement models

Fixed-scope, dedicated team, or discovery first

Each has a real trade-off. We’ll recommend the one that fits your situation, including when that means less work for us.

Fixed-scope project

We define the scope precisely, then quote a fixed price and timeline against it. Changes go through a written change request so the number never moves quietly.

Good for: Well-understood projects with a clear finish line — a website, a defined MVP, a specific integration.

Trade-off: Requires real discovery before we can quote, and rewards clear thinking up front. It is the wrong model when the requirements are genuinely still unknown, because pricing uncertainty means pricing risk into the number.

Dedicated team / retainer

An agreed number of engineers and designers work with you continuously, planned in two-week sprints, with priorities reset each sprint.

Good for: Ongoing product development where priorities change with what you learn from users.

Trade-off: No fixed end date, so it needs an engaged product owner on your side to direct the work and protect the value.

Discovery engagement

A short, paid, standalone piece of work producing a technical plan, architecture, scoped backlog and a firm estimate.

Good for: Large or ambiguous projects where an accurate estimate is impossible without real investigation.

Trade-off: An extra step before build starts — but far cheaper than discovering the same unknowns halfway through a fixed-price build.

Support and maintenance

An ongoing arrangement covering monitoring, updates, security patching, bug fixes and small enhancements.

Good for: Live products that need to stay secure, current and reliable after launch.

Trade-off: Sized to the product's actual needs rather than sold as a flat package, so it requires an honest conversation about what you genuinely need.

Timelines

Where the time actually goes

Discovery and scoping

Requirements, technical approach, scoped backlog, fixed-scope estimate.

Skipping this is the most expensive shortcut available in software.

Design

User flows, wireframes, high-fidelity UI, an approved prototype.

Changing a screen in Figma takes minutes. Changing it in production takes days.

Build

Working software delivered in two-week sprints, reviewable each sprint.

You see progress continuously rather than waiting for a single reveal at the end.

Testing and hardening

QA, performance work, security review, accessibility checks.

Runs alongside build rather than being bolted on at the end.

Launch

Production deployment, monitoring, analytics, handover documentation.

You receive the code and the infrastructure. There is no lock-in.

Post-launch

Support, iteration on real usage data, ongoing improvements.

The first month of real users teaches more than the whole build did.

Business value

Four questions that tell you if it’s worth building

Worth answering before you talk to any agency, including us.

What does the current process cost you today?

Hours spent on manual work, multiplied by loaded salary, multiplied by a year. This is usually the clearest number in the whole business case, and the one most often left uncalculated.

What is a single additional customer worth?

Average contract value multiplied by expected lifetime. If the product plausibly wins a handful of extra customers a year, that alone often covers the build.

What is the cost of not doing it?

Lost deals to better-equipped competitors, staff churn from bad internal tooling, or the compounding cost of a system that gets more expensive to change every month it is left alone.

How quickly do you need payback?

A twelve-month payback expectation argues for a narrow, focused MVP. A three-year horizon justifies building for scale from the start. Both are valid — but they produce genuinely different projects, so it is worth deciding deliberately.

What is being priced

The six kinds of work these numbers cover

Every estimate on this page resolves to one of these, or to a combination of them. Each page sets out what the work involves and what shapes its cost.

Pricing FAQ

The questions buyers actually ask.

Straight answers on cost, scope, ownership and how changes are handled. Anything we haven't covered?

It depends far more on scope, integrations, data readiness and compliance requirements than on the number of screens or the technology used. Rather than quote a range that could not apply to your situation, we run a free 45-minute consultation, establish which factors actually apply to you, and give you a fixed-scope estimate you can rely on.

Next step

Get a fixed-scope estimate for your project

A free 45-minute call. We'll scope the work, flag the risks, and tell you what it takes — whether or not you build it with us.

business@futurisesolutions.com