Are you SOC 2 certified?

No, and it is worth knowing that strictly speaking nobody is. SOC 2 is an attestation report issued by a CPA firm against the AICPA's Trust Services Criteria — there is no certificate, no pass mark, and no certifying body, so any supplier describing themselves as SOC 2 certified is describing something that does not exist. If your procurement process requires a SOC 2 Type II report, ask for the report itself rather than the claim, and check the period it covers and which criteria were in scope.

How do you handle CCPA and other US state privacy laws?

As engineering requirements rather than a policy document. Twenty states have comprehensive privacy laws in effect during 2026, so the practical work is making the system able to locate, export and delete one identified person's data on request without an engineer writing a one-off script, and making deletion actually reach backups, event logs and analytics rather than only the primary table. We raise this during scoping because retrofitting it into a live system costs considerably more than designing it in.

Can you build HIPAA-compliant software?

Yes. Where protected health information is in scope we build to HIPAA's technical safeguards — access control, audit trails, integrity verification and transmission security — and a Business Associate Agreement governs the arrangement where one is required. The most valuable decision is usually made early and cheaply: keeping the number of systems that touch PHI as small as possible, because every service inside that boundary inherits the obligation and the testing burden that comes with it.

How much does custom software development cost in the US?

It depends on four things more than any others: how many external systems the software must stay in sync with, how much of the data is regulated, how much existing code has to be understood before anything can change, and how precisely the scope is defined. Rather than asking you to book a call to find out, we publish detailed cost breakdowns for custom software, SaaS platforms and AI agents that you can read and compare against quotes you already have.

How do you compare with a US-based agency?

There are engagements where a domestic agency wins outright, and we would rather name them than compete for work we are not suited to: live systems needing same-hours incident response, and contracts restricting data access by location. Our advantage sits elsewhere — specialist depth a single agency is unlikely to keep idle, covering production LLM and retrieval engineering, audited smart contracts and computer vision, plus sustained throughput against a scope already defined in writing.

How do you handle working across time zones?

By designing the workflow around the gap rather than treating it as a scheduling problem to solve case by case. Overlap with your working day is agreed during scoping and written into the engagement, and you have a named engineer instead of questions relayed through an account manager. Left unmanaged, a time difference turns a one-day question into a three-day round trip — but that is a process failure rather than a geography one, and it is avoidable.

What happens on the first call?

It is a working session rather than a sales meeting. We map the system you have today, the outcome you are trying to reach, and which parts of your data carry regulatory obligations that will shape the architecture before a line of code exists. You leave holding a written scope detailed enough to hand to a second supplier for a comparable quote, and the estimate follows from that document. Your NDA is signed before we review anything confidential, including in that first conversation.

United States

Software development for United States businesses

Q: Who owns the code and the intellectual property?

This should be settled in writing before a repository exists, and we confirm our position in the engagement documents rather than only on a call. Four questions are worth answering explicitly with any supplier: who owns the resulting code, at what point ownership transfers, whether that transfer is an assignment or a licence, and whether the supplier retains rights over reusable components that end up in your codebase. Ask all four, and get the answers in the contract rather than the proposal.

Q: What happens if we end the contract early?

Engagements end for reasons unrelated to quality — funding moves, priorities shift, people leave — so the terms are worth agreeing at the start rather than during a disagreement. Establish what notice each side gives, what you receive for work completed to that point, and how repository, environment and infrastructure access transfers back to you. We set these out in the engagement documents specifically so there is nothing to interpret if the circumstances ever arise.

Custom software, AI and SaaS built for companies serving US customers — scoped against the twenty state privacy regimes now in force, quoted on fixed scope rather than an hourly meter, and delivered by a named engineer you can reach directly. We publish our cost ranges, and we answer the two questions most suppliers avoid — where we are actually based, and what SOC 2 compliance really means.

Send us your scope

The record

Six engagements, and the gap they leave

The compliance arguments below are worth what the delivery record behind them is worth, so the record comes first — including the part of it that is missing.

Six builds for businesses selling into the US

Six of the seven projects on our portfolio were delivered for companies operating in the US market. They run from a property-management platform reporting income, expenses and occupancy across large listing portfolios, to an AI review-capture product aimed at chains with many locations, a luxury jewellery storefront covering fine pieces, watches and bullion, a real-estate search platform structured so individual listings can be found through organic search, a perpetuals trading terminal dense enough for full-time traders, and a hotel booking flow built to take reservations directly rather than surrender them to an intermediary.

Where the record stops

None of it is a HIPAA engagement, and none of it is a PCI DSS programme. This page argues both at length further down, and our published record evidences neither — so if regulated health data or card-data scope is central to what you are building, ask us for specifics rather than reading them into the list above. Several of these clients also operate across the United States and India rather than being US companies outright, which is the accurate description of the market involved.

No one project covering for the rest

The six span platform analytics, an AI product, e-commerce, search-led web, a trading interface and booking design, and each one belongs to a different client. That matters because the usual failure in a supplier's portfolio is a single strong project quietly standing behind every capability claimed elsewhere on the site. These are separable: any one can be examined on its own without the others holding it up, and each is published with the problem it solved and screenshots of what shipped.

See these projects on our portfolio

The market

What building software for the US actually changes

Most of what makes the United States different for software is regulatory, and almost all of it lands in the architecture rather than in a policy document. These are the four that change engineering decisions.

Privacy here is twenty laws, not one

Twenty states have comprehensive consumer privacy laws in effect during 2026, and twenty-four have now enacted one. The gap between those two numbers matters: a law that is enacted but not yet in force still sets a date you are building toward, and the schedule is continuous rather than occasional — Indiana, Kentucky and Rhode Island all came into effect on 1 January 2026. No single federal statute overrides them. For software the consequence is that compliance is not a yes-or-no property of your product. It is a question of which user triggers which obligation, and whether your system can tell the difference at the moment it matters rather than during an audit six months later.

Compliance decisions land in the architecture, not the policy page

Once more than one state regime applies, three engineering decisions stop being optional. Whether a record can be located and exported for one identified person without an engineer writing a script. Whether deletion propagates through backups, event logs and downstream analytics rather than only the primary table. And whether consent state travels with the data instead of living in a separate marketing tool that nobody thinks of as part of the system. Each is a modest design decision at the start and a migration once real customer data exists. We raise all three during scoping for that reason, not because they make the estimate look thorough.

Health and payment data raise the floor

HIPAA applies wherever protected health information is handled, and its technical safeguards — access control, audit trails, integrity verification, transmission security — are engineering requirements rather than documentation exercises. Where a vendor processes that data on your behalf, a Business Associate Agreement governs the relationship. Payment data brings PCI DSS, whose practical effect is usually the opposite of what people expect: the goal is to shrink scope, because the fewer systems that touch card data, the smaller and cheaper the compliance surface becomes. Both are ultimately decisions about where system boundaries sit, and both are far easier to make before the first schema exists than after.

AI systems now carry rules of their own

The Texas Responsible Artificial Intelligence Governance Act took effect on 1 January 2026, and it reads as a signal rather than an outlier: AI features are moving from unregulated to governed while most products are still being built. For a team shipping an LLM or agent feature today, three capabilities are worth designing in now rather than retrofitting under deadline. Being able to show what a model was given and what it returned. Keeping a human decision point wherever the output materially affects a person. And knowing precisely which data left your boundary to reach a third-party model, because that answer is difficult to reconstruct later.

US-based vs distributed

The honest version of the offshore question

Every US buyer weighs this, and most suppliers answer it by claiming their own model always wins. It does not. Here is where each genuinely does, including the cases where we are the wrong choice.

Where a US-based team genuinely wins

Live revenue systems where an incident at two in the afternoon Eastern needs someone already awake, already holding context, and already able to deploy.
Contracts that restrict who may access data by citizenship or physical location, which some federal, defense and large healthcare agreements do explicitly.
Discovery inside a regulated environment, where the real requirements only surface by sitting beside the people doing the work and watching what they actually do.
Organisations where the binding constraint is internal alignment rather than engineering, and progress depends on someone chasing decisions in person.

Where distributed delivery genuinely wins

Specialist capability no single agency keeps idle on the bench — production LLM and retrieval engineering, audited smart contracts, computer vision pipelines.
Sustained throughput against a scope that is already defined, where the limit is engineering hours available rather than meeting slots in a calendar.
Budgets that need to buy engineering rather than overhead, so a larger share of the money reaches the build instead of the account layer above it.
Work that continues while your team sleeps, so a review left on Friday afternoon has an answer waiting rather than a two-day gap in the middle of it.

Where distributed delivery fails, and why

Work handed over without a written specification, then rebuilt twice at your cost while both sides remain convinced they were perfectly clear the first time.
A time-zone difference treated as a scheduling inconvenience rather than something the workflow is deliberately designed around from the first week.
No named engineer, so every technical question is relayed through someone who cannot answer it and returns a day later with an approximation.
Hourly billing with no fixed ceiling, which quietly rewards the supplier for the work taking longer than either side originally expected.

How the engagement actually runs

A scoping conversation before any number exists

The first call establishes what you are building, what already exists in your stack, where the real constraint sits, and which parts of your data carry regulatory obligations. It is a working session rather than a pitch, and the output is a shared understanding of the problem instead of a proposal deck. If the honest answer is that you do not need us, or that what you want is cheaper to buy than to build, we will say so on that call.

A written scope you can take away

You leave with the scope in writing, in enough detail to hand to another supplier and get a comparable quote back. That matters more than it sounds: most disputes on software projects trace to a scope that lived only in someone's memory of a conversation. An estimate follows from that document, and when the document changes the estimate changes with it, visibly.

A named engineer, not an account manager

During delivery you have direct access to the person writing the code. Questions that a project manager would have to forward and return on get answered by someone who can already see the answer on their screen. It also removes a failure mode common to larger suppliers, where the person who understands your system and the person who talks to you are never the same person.

Working hours agreed at the start

Overlap with your working day is settled during scoping and written into the engagement, so review cycles are predictable from week one rather than discovered in week three. A time difference is only a problem when nobody has decided what it means in practice, and deciding it takes one conversation at the start rather than a month of missed handoffs. The same applies to escalation: knowing in advance who to contact when something breaks outside the overlap window is worth more than a promise that nothing will.

Ownership & exit

Who owns what, and what happens if it ends

Four things worth settling in writing during onboarding, with any supplier. They are administrative when agreed at the start and expensive when agreed later.

Settle ownership before work starts, not after

Who owns the resulting code, at what point ownership transfers, and whether that transfer is an assignment or a licence are questions with genuinely different answers at different suppliers — and all three are cheap to agree before a repository exists, expensive to argue about once a product is live and funded. Ask any supplier to state their position in the engagement documents rather than describing it on a call, and ask specifically whether they retain rights over reusable components or internal libraries that end up in your codebase. A supplier who cannot answer that clearly has not thought about it, which is itself useful information about how the engagement will run.

Confidentiality before anything is shared

We sign your NDA before reviewing anything confidential. That covers the discovery stage, where you are describing systems, roadmaps and commercial context long before any contract exists — which is precisely the window most often left uncovered, because both sides are still deciding whether to proceed. If a supplier wants access to your data room or your codebase before any confidentiality agreement is in place, treat that as information about how they operate rather than an administrative detail to sort out later.

Write down what happens if it ends early

Engagements end for reasons that have nothing to do with the quality of the work: funding moves, priorities change, a founder leaves, a board decides differently. Three terms are worth agreeing at the start — what notice each side gives, what you receive for work completed to that point, and how repository, environment and infrastructure access transfers back to you. Agreed up front these are administrative paperwork that takes an afternoon. Agreed during an actual disagreement they are neither quick nor cheap, and the party without them written down is usually the one that concedes.

Plan the handover while you still need it

The real measure of a finished engagement is whether your team can keep moving without the people who built the thing. In practice that means documentation that survives someone leaving, environment setup another developer can follow without a call, and architectural decisions recorded with the reasoning behind them rather than only the outcome — because the reasoning is what tells a future engineer whether a decision still applies to a situation nobody anticipated. Establish during scoping whether that work sits inside the engagement or arrives as a separate line item, since the two produce very different final invoices and only one of them is a surprise.

Quoting & estimates

How we price work for US projects

Most suppliers in this market publish no pricing information at all. We publish how an estimate is built, and detailed cost ranges you can read before you speak to anyone.

What actually moves an estimate

Four things account for most of the distance between a cheap quote and an expensive one. How many external systems the software has to stay in sync with, because each one is a contract you do not control. How much of the data is regulated, which sets the floor on access control, logging and testing. How much existing code has to be understood before anything can safely change. And how precisely the scope is defined, which is the only one of the four the buyer fully controls. An estimate produced before those are known is a guess with a number attached to it.

Fixed scope rather than an open hourly meter

We scope the work, then quote it. If our estimate turns out to be wrong on our side of the line, absorbing that is our problem rather than a variation to bill back to you. Hourly billing pays a supplier more the longer the work takes, which is precisely the wrong incentive when the outcome is fixed and the buyer is the one carrying delivery risk. Fixed scope also forces a conversation about what is genuinely in the build before anyone starts, which is where most of the value of the exercise actually sits.

No published rate card, and the reason

We publish how a price is built instead of a headline figure, because a number quoted before anyone understands the scope is wrong for almost everyone who reads it — too high for the simple case, too low for the complex one, and useless for comparing suppliers. What drives an estimate is written out in full on our pricing page, and the cost guides below work through real ranges for specific project types so you can calibrate against something concrete rather than a marketing number.

Numbers you can check before you call

Rather than requiring you to book a call to find out whether your budget is even plausible, we publish detailed cost breakdowns for AI agents, SaaS platforms and custom software builds, with the ranges broken out by scope and complexity. You can read them, compare them against quotes you already hold, and arrive at the first conversation knowing whether the numbers are in the same universe. That is a deliberately unusual position in a market where most suppliers publish nothing at all, and it exists because a sales call is an expensive way for either side to discover a mismatch that a published range would have settled in a minute.

See what drives an estimate

Fifty states, one architecture

Scoped against the privacy regimes actually in force where your users are.

Where we work

What US businesses ask us to build

Four sectors we are asked about most, described by the shape of the engineering problem rather than by listing client names we are not free to publish. In each one the decisive choice is architectural and gets made early, which is why they are worth recognising before a build starts rather than during it.

Healthcare and digital health

Patient-facing applications, clinical workflow tools, and the integration layer that connects them to systems nobody wants to replace. The engineering problem is almost always the boundary: which services hold protected health information, which merely reference it, and how audit trails stay intact as data crosses that line. Draw the boundary tightly and the compliance surface stays small enough to reason about. Draw it loosely and every service in the architecture inherits the obligation, which shows up later as a testing burden nobody estimated.

Fintech and financial services

Ledgers, reconciliation engines, reporting layers, and the payment flows running underneath all of it. These builds are decided by correctness under partial failure rather than by feature count — what the system does when a payment provider commits and then times out, or when a webhook arrives twice, or when two updates race for the same balance. A reporting dashboard that disagrees with the ledger by a single cent is a dashboard nobody opens again, and rebuilding that trust costs more than building it correctly did.

B2B SaaS

Multi-tenant platforms where the genuinely hard problems arrive with the second enterprise customer rather than the first. Per-tenant data isolation that holds under a misconfigured query. A role model that survives contact with a real org chart. Single sign-on against an identity provider you do not control. And usage metering accurate enough to raise an invoice from without anyone checking it by hand. Every one of those is inexpensive to design in at the start and disproportionately expensive to introduce once production data exists.

Retail and e-commerce

Storefronts, subscription billing, and the operational systems that keep them supplied. Two constraints shape the architecture more than any product decision: sales tax varies by jurisdiction and changes without consulting your roadmap, and traffic is spiky enough that the system has to be inexpensive at baseline while absorbing an order-of-magnitude peak without manual intervention. Both are architecture decisions rather than hosting ones, and both are considerably cheaper to make before the first checkout goes live.

Integrations

The systems your software has to talk to

Most US business software is an integration problem before it is a build problem. These are the connections we are asked for most.

Stripe

Subscription billing, usage-based pricing, and checkout flows across currencies — including the webhook handling and idempotency work that keeps billing correct when the network is not.

Salesforce

Two-way synchronisation so pipeline data and product data stop disagreeing, with conflict rules decided deliberately rather than by whichever system happened to write last.

HubSpot

Lifecycle and marketing automation wired to real product events instead of page views, so the sequence a customer receives reflects what they actually did in the product.

Snowflake

Analytics pipelines that report from the warehouse rather than the production database, which keeps a heavy quarterly report from competing with live customer traffic.

Plaid

Bank account linking and transaction data for financial products, including the reconnection and consent-expiry paths that most implementations discover only after launch.

Twilio

Messaging and voice, together with the consent capture and opt-out handling those channels require — the part that is a compliance obligation rather than a feature.

Services & cost guides

What we build, and what it costs to build it

Every service below is available to US clients, and every cost guide below is already published rather than gated behind a form. Read the guide that matches your project before booking anything — if the ranges do not fit your budget, that is a useful answer to reach on your own terms rather than on a sales call.

Services available to US clients

Web Development

Sites & web apps

App Development

iOS & Android

UI/UX Design

Product design

Blockchain Development

Web3 & dApps

AI & ML Solutions

Agents & automation

Digital Marketing

SEO & growth

Cost guides we have published

Custom Software Development Cost Guide 2026

Pricing, timeline, and the factors that move an estimate more than anything else.

SaaS Development Cost Guide 2026

What a SaaS build costs by stage, and where the budget actually ends up going.

How Much Does a Custom AI Agent Cost in 2026?

A breakdown by capability, from a scoped pilot through to a production deployment.

AI Agent Development Cost 2026 — Global Price Comparison

What the same AI build costs across markets, and why the spread is that wide.

Building a Custom AI Agent: ROI and Tech Stack Guide

Written for US and Canadian startups — architecture choices, model selection, and how to build the return case before committing budget.

Read our case studies Who you would be working with

United States FAQ

Questions from US buyers.

The things US enquirers ask before the first call, including the two most suppliers avoid answering. If yours is not here, send it over.

No. Futurise Solutions is registered in Wellington, New Zealand, and our engineering team is distributed. That belongs at the top of the answer rather than buried in a footer, because it changes how you should evaluate us. The structure buys specialist depth — production AI, blockchain and mobile engineering — instead of only the skills a single local office happens to have hired. It does not buy someone who can be in your building on Thursday afternoon, and where a project genuinely needs that, we will say so.

Start in the United States

Building something for the US market?

Book a scoping call, or send us the scope and we'll come back with a fixed-scope estimate and a written understanding of what you are building.

business@futurisesolutions.com