Pick the shape of the work.
How we work together depends on how certain your scope is and how long you need help. Here are the four shapes we offer, a scoper that suggests one, and straight answers about pricing, ownership, and life after launch.
M-1Certainty first
Fixed-scope project
We agree on a written scope, a timeline, and a fixed price after a discovery sprint, then deliver in two-week sprints with a demo at the end of each one.
- Best for
- A clearly defined build that is unlikely to change much once it starts.
- Pricing
- One fixed price for the agreed scope, set after discovery. Changes go through a short written change request with its own estimate.
- Starts with
- A discovery sprint, then a statement of work.
- Trade-off
- Certainty about cost in exchange for less room to change course mid-build.
M-2Learning first
Product sprint
A fixed team for a set number of two-week sprints at a set cost per sprint. The scope is a prioritized backlog that we re-plan with you every sprint.
- Best for
- New products, MVPs, and first releases, where what you learn will change the plan.
- Pricing
- Per sprint, agreed up front for the team and the number of sprints.
- Starts with
- A discovery sprint, which can count as the first sprint.
- Trade-off
- The calendar and budget are fixed, so lower-priority items may move to a later release.
M-3Capacity first
Dedicated team
A standing team, for example a designer, two engineers, and part-time QA, assigned to your product month to month and working from your backlog in two-week sprints.
- Best for
- Larger builds, long roadmaps, and products that change every month.
- Pricing
- Monthly, based on the team's makeup. Scale up or down with notice.
- Starts with
- A short onboarding, or a discovery sprint for a new product.
- Trade-off
- Works best with a steady stream of work and someone on your side who owns priorities.
M-4Health first
Care plan
Monthly maintenance for software that is live: dependency and OS updates, app store changes, monitoring, bug fixes, and a block of time for small improvements.
Platforms move every year. For example, Google Play has required new apps and app updates to target Android 16 (API level 36) since August 31, 2026, and Apple has required App Store uploads to be built with Xcode 26 or later since April 28, 2026. A care plan keeps your app ahead of changes like these.
- Best for
- Products we built, and products other teams built, after a code review.
- Pricing
- A monthly fee for an agreed number of hours and response targets, set in writing.
- Starts with
- A handover, or a code and infrastructure review if someone else built it.
- Trade-off
- Sized for upkeep and small changes. Larger features run as a product sprint.
Scope it in a minute.
Choose a platform, the features you need, and the systems it has to connect to. The scoper suggests an engagement model and a phase timeline in week ranges.
Show the math
Estimates only. These ranges come from simple planning rules, not from your project. They assume a small team (a designer, two engineers, part-time QA, and a project lead), feedback from one decision-maker within a few working days, access to the systems involved, and no regulated-data work such as HIPAA. A discovery sprint replaces them with a written estimate.
Pricing, ownership, and what comes after.
Q-01How do you approach pricing?
We do not publish prices, because the cost of software depends on scope, risk, and team size, and a number without that context does not help you plan. Here is how pricing works instead.
Discovery is a short engagement with a fixed price agreed before it starts. At the end of it you get an estimate as a range, with every assumption written down, and a recommended engagement model. Fixed-scope projects then get one fixed price; product sprints and dedicated teams are priced per sprint or per month; care plans are monthly. You know the cost before work begins, and each weekly update shows spend against plan.
Q-02Who owns the code and the intellectual property?
You do. Once the work is paid for, the code, designs, and documentation we create for you belong to you, as set out in our written agreement. We work in repositories, cloud accounts, and app store accounts that you own from the first day, so there is nothing to hand back at the end.
Open-source libraries keep their own licenses. We list the ones we use so your team knows its obligations.
Q-03How will we communicate?
Email for anything that needs a record, a written update every week, a demo every two weeks over video, and a shared backlog you can read at any time. You have one main contact on our side who knows your project from end to end.
Q-04What happens after launch?
We watch the first weeks closely, fix launch issues, and walk your team through the runbook. After that you choose: a care plan with us, a new product sprint for the next release, or taking the code in-house. Because the code, documentation, and accounts are already yours, any capable team can pick the work up.
Q-05Can you take over software another team built?
Often, yes. We start with a code and infrastructure review, then tell you plainly what we found and whether we recommend maintaining, refactoring, or rebuilding parts of it.
Q-06Will you sign an NDA?
Yes. We are glad to sign a reasonable mutual NDA before you share the details of your idea or your systems.
Q-07How accurate are your estimates?
Every estimate is a range, and the range narrows as we learn. Discovery narrows it the most, because it replaces guesses with decisions. During the build, the weekly update tracks progress against the plan, so any change in the forecast shows up early, while there is still time to adjust scope.
Turn the estimate into a plan.
A discovery sprint replaces these ranges with a written scope, a timeline, and a price.
contact@hilltechlabs.com