Services

Usually, yes. There is no federally approved list of TABA vendors; you propose one and the agency reviews the request. Common requirements are that the vendor be a legal U.S. business and not your own company, an employee, or an affiliate or investor of yours, and agencies with a default provider may ask you to justify going outside it. Since your chosen vendor goes into a federal proposal under your name, vet them the way the agency will: fixed price and deliverables in writing, named people doing the work, and everything they produce owned by you.

At most agencies, inside your Phase I or Phase II proposal: a named dollar amount in the budget, a justification describing the services and expected benefits, and usually the identified vendor. The variations matter, so read the TABA section of your agency's current solicitation first. Some agencies route the assistance through a preferred vendor unless you justify your own choice, some have allowed funds to be added to an existing award by administrative supplement, and some won't accept a TABA request after the application is submitted. If you're already past submission, ask your program office what's still possible.

Often, yes, when the software is the commercial expression of the research your agency funded. The statute's stated purposes include developing and commercializing the products that result from the project, and product definition, prototyping, and production development are commercialization work in that plain sense. Agencies interpret eligible uses through their own solicitations, though, so frame the request in commercialization terms and confirm it with your program office before counting on it. Worth knowing: most established TABA vendors deliver reports, and a product real customers can use is often the stronger commercialization evidence.

Up to $6,500 on a Phase I award and up to $50,000 on a Phase II award, generally in addition to the research award itself. The exact amounts, whether the funds come on top of or inside your award, and the request process all vary by agency, so your agency's current solicitation is the authority. One practical effect of the caps: they make fixed-price vendor work easy to justify, because a TABA budget line wants a specific dollar figure and a described deliverable, which is exactly what a fixed-price engagement puts in writing.

TABA stands for Technical and Business Assistance: supplemental federal funding that SBIR and STTR awardees can request to pay outside vendors for help commercializing their funded research. It was created by the fiscal 2019 National Defense Authorization Act and extended by the 2026 SBIR/STTR reauthorization, and it sits on top of the research award rather than inside it. Think of it as the program admitting that funded research doesn't become revenue on its own. The money exists so you can buy the commercial expertise your research team doesn't carry, without spending R&D dollars to get it.

Yes. The standard pattern is to keep the current app running (with critical fixes only) while the new version is built in parallel, then ship the rebuild as an update to the same store listing so you keep your ratings, reviews, and install base. Users download an update, their accounts and data carry over, and nothing resets. The cutover plan deserves as much scrutiny as the build quote: ask for the migration steps, the rollback plan, and who handles store review in writing.

Source code and repository access, app store and developer accounts, backend and database access, third-party service credentials (payments, analytics, push), any documentation, and the contact for whoever built it, if they're reachable. Gaps are normal; a good takeover partner lists what's missing and works around it. Before you hand anything over, confirm you actually own the accounts and the code under your current contract. If the old developer controls the store listing or the repo, recovering access is the real first project.

No. Sequencing is normal: rebuild the platform with the most users or the worst problems first, prove the new foundation, then bring the second platform over. A cross-platform rebuild (one codebase serving both stores) is the other common answer, and it often comes out of the audit as the cheaper path forward. The right order depends on where your users and your pain actually are, so ask any agency to justify their sequencing against your analytics rather than their staffing calendar.

A focused rebuild generally lands in the same territory as a first build of comparable scope, because scope drives cost; the published ranges in our cost guide ($25k to $75k for a focused first version) are the honest starting point. What moves the number is how much survives the audit: a solid data model or API layer can carry over and shrink the quote. That's why the audit comes before the price. Be wary of any rebuild quoted without one; a price set before the code is read is a guess, and it gets corrected at your expense.

At minimum: a written scope, line-item pricing, a timeline with milestones, who owns the code (you), the names and roles of the team, and what post-launch support costs, typically 15 to 20% of build cost per year. If strategy and design work are included, the proposal should say what they produce, not just that they happen. A proposal missing the year-two number isn't cheaper, it's incomplete. Compare any two proposals on the five-year total and the order often changes.

Yes, and the good ones do it constantly: prototypes from freelancers, internal teams, no-code tools, and AI builders all land on commercialization firms' desks. The takeover should start with a code review that tells you what's worth keeping before anyone proposes a rebuild. At Iron Forge that review happens inside a fixed-price Discovery, which returns written findings, line-item pricing, and a timeline in 2 to 3 weeks. Ask any partner you're evaluating to put their keep-versus-rebuild recommendation in writing; it's the cheapest way to find out how they think.

Prototype-to-product is the work between a demo that impresses a meeting and software that paying customers rely on: hardening the code, designing real workflows, adding the unglamorous parts (accounts, billing, permissions, monitoring), and preparing support for launch. A prototype proves the idea; a product survives strangers using it at volume. Ask any firm pitching prototype-to-product services which parts of your prototype they would keep. A specific answer means they've done this before. A promise to rebuild everything, quoted on the first call, means they haven't read your code yet.