Straight answers
Frequently asked questions
Straight answers about how we work, what things cost, and what happens after launch. If your question isn't here, ask us and we'll answer it plainly.
01Working with us
How a project starts, who you talk to, and how we run the day to day.
How do we start a project with you?
It starts with a call. You tell us the problem, where the product is today, and what a good outcome looks like. We ask questions, sketch a rough shape and a realistic plan, then send a written proposal with scope, timeline and price. If the fit is right on both sides, we sign and start. No long sales cycle, and we'll say so early if we're not the right team for the work.
Which engagement model should we choose?
Pick a dedicated team for ongoing product work with a roadmap, staff augmentation when you have a team and a plan but need more hands or a specific skill, and a fixed-scope project when the requirements are clear and there's a firm deadline. If you're unsure, we'll talk it through and recommend the honest fit. Our engagement models page lays out all three side by side.
Who will we actually be working with?
The engineers and designers building your product, not a layer of account managers. You get a named point of contact who knows the work, and direct access to the people writing the code. We keep teams small and senior so nothing gets lost in translation, and you'll see a working build regularly rather than a slide deck at the end.
Do you only work with EdTech and real estate companies?
Those are our two deepest verticals, so we move fastest there. But we've built across fintech, healthcare, logistics, e-commerce and more. The engineering is the same; the domain knowledge is what we bring extra in EdTech and real estate. See services for what we build and work for examples.
02Pricing and contracts
How we price work, what the contract covers, and how billing runs.
How do you price a project?
It depends on the model. A dedicated team and staff augmentation are billed monthly, per team or per person. A fixed-scope project is a set price tied to milestones. We share the shape of the cost up front and put the detail in the contract. We won't quote a firm fixed price until the scope is clear enough for us to stand behind it.
Can you give a fixed price for the whole build?
Sometimes, and we're happy to when the requirements are well understood. For genuinely fixed-scope work we price by milestone with a clear acceptance check at each one. For products that will keep changing, a fixed price for everything usually hides the cost of change rather than removing it, so we'll be honest about when fixed pricing helps and when it doesn't. Our note on build vs buy goes deeper on this trade-off.
What does the contract include, and how does billing work?
Scope, timeline, price and payment terms, plus the parts that protect you: you own all the code and IP, confidentiality runs both ways, and there's a clear way to change scope and to end the engagement. Monthly engagements are invoiced monthly in arrears; fixed-scope projects bill against milestones as each is accepted. We keep contracts readable and don't lock you into long minimum terms beyond what the work needs.
03Timelines and delivery
How long things take, how we estimate, and how we ship.
How long will my project take?
A focused first version of a product is often a few months; a larger platform is longer and usually best built in stages. The honest answer needs your specifics, so after a scoping conversation we give a realistic range, not a number designed to win the deal. We'd rather under-promise and hit the date than the reverse.
How quickly can you start?
Staff augmentation is usually quickest, since people slot into your existing setup. A dedicated team takes a little longer to assemble and learn the domain. A fixed-scope project begins with a short scoping phase before the build. Once we understand the role and the work, we'll give you a real start date.
How do you handle changes once we've started, and what if it runs late?
On a dedicated team you reprioritise the next sprint, since that model is built for change. On a fixed-scope project, a change to the agreed scope goes through a short written change request so the timeline and price stay honest. If the work starts to slip you hear it early, with the cause and a plan to recover, not a surprise at the deadline. Our process page walks through how we plan and ship.
04Technology and code
The tools we use, how we keep quality high, and how we write code.
What technologies do you build with?
We pick the stack to fit the product, not the other way round. In practice that's usually modern, well-supported tools with a large hiring pool, so you're never stuck with something only we can maintain. We'll explain the choices in plain terms and avoid anything exotic without a clear reason. Our services pages list the kinds of work we take on.
Will the code be easy for another team to pick up?
Yes, that's a deliberate goal. We write readable code, document the parts that matter, use standard patterns, and keep the build and deploy steps simple. The test is whether a competent engineer who has never seen the project can get it running and make a change. We build so the answer is yes.
How do you keep quality high?
Code review on every change, automated tests where they earn their keep, and a security and accessibility check before releases. We'd rather catch a problem in review than in production. Quality assurance is part of how we work, not a phase bolted on at the end.
Can you take over an existing or legacy codebase?
Yes. We start by reading the code and the history, mapping what's there, and finding the riskiest parts before we change anything. Then we stabilise, document, and improve in small, safe steps rather than a risky big-bang rewrite. Our note on rebuild vs re-engineer covers when to rebuild versus repair, and our work has examples of taking over running systems.
05Support, handover and ownership
What happens after launch, how handover works, and who owns what.
Do you stay involved after launch?
Yes. Launch is the start of a product's life, not the end of ours. We offer ongoing support and maintenance, and many clients keep us on a rolling basis to keep things fast and reliable and to build the next thing. If you'd rather take it fully in-house, we make that clean too.
What does handover look like?
A documented one. You get the code, the accounts, the deployment steps, and a written guide to how the system fits together, plus a walkthrough with your team. We don't keep knowledge hostage. The point of handover is that you can run and extend the product without us if you choose to.
Who owns the code and the accounts, and what if we want to stop?
You own everything: the code, designs, data and cloud accounts are yours, and we assign the IP to you in the contract. We work in your repositories and accounts where you prefer. If you ever want to end the engagement, the contract sets out a clear notice period and an orderly handover, so you leave with everything you need. Owning your own software is one of our standing commitments, not an upsell.
06Security and data
How we handle access, sensitive data, and the rules your sector lives by.
How do you handle security?
Security is built into how we work: least-privilege access, secrets kept out of the code, dependencies kept current, and a security review before releases. We work inside your accounts and access controls where you prefer, and we're glad to follow your security policies and sign the agreements your team needs.
How do you protect our data and our users' data?
We collect and keep only what the product needs, separate environments so real user data isn't used loosely in testing, and put access controls and encryption in place as standard. We treat your data as yours, handle it under a written agreement, and design data flows so privacy is the default, not an afterthought.
Do you understand the rules in regulated sectors like EdTech?
Yes. In EdTech we build with student-data privacy expectations such as FERPA and COPPA in mind, and in real estate we respect MLS and IDX listing-data rules. We don't claim certifications we don't hold; what we do is design systems that make it easier for you to meet your obligations. See industries for how this shows up per sector.
Will you sign an NDA and our security paperwork?
Yes, gladly, and usually before any sensitive detail is shared. Confidentiality runs both ways in our standard contract, and we're used to completing client security questionnaires and data-processing agreements. If your team has specific requirements, tell us early and we'll work to them.
Still have a question?
Tell us what you're trying to build and where your team is today. We reply to every serious enquiry within one business day, with a straight answer.