--- title: "How to Choose a Custom Software Development Partner: 12-Point Checklist | TetraCore" description: "A practical, vendor-neutral checklist for choosing a custom software development partner — shipped products, code ownership, security posture, post-launch operations, and the red flags to walk away from." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Article", "headline": "How to Choose a Custom Software Development Partner: A 12-Point Checklist", "description": "A practical, vendor-neutral checklist for evaluating custom software development partners: shipped products, code ownership, security posture, post-launch operations, estimation practices, and red flags.", "url": "https://tetracorehq.com/insights/how-to-choose-software-development-partner", "mainEntityOfPage": "https://tetracorehq.com/insights/how-to-choose-software-development-partner", "image": "https://tetracorehq.com/lovable-uploads/8cd6dd97-bd06-4c50-9f72-5f69e8f9c862.png", "datePublished": "2026-07-09", "dateModified": "2026-07-14", "author": { "@type": "Person", "name": "W. Miller", "worksFor": { "@type": "Organization", "name": "TetraCore", "url": "https://tetracorehq.com" } }, "publisher": { "@type": "Organization", "name": "TetraCore", "url": "https://tetracorehq.com", "logo": { "@type": "ImageObject", "url": "https://tetracorehq.com/tetracore-logo.png" } } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What should I look for in a custom software development partner?", "acceptedAnswer": { "@type": "Answer", "text": "Look for evidence over promises: shipped products you can actually try, clarity about who writes the code, a real security posture, unambiguous source-code ownership in the contract, a plan for post-launch operations, and references from projects that resemble yours in size and shape." } }, { "@type": "Question", "name": "What are red flags when hiring a software development company?", "acceptedAnswer": { "@type": "Answer", "text": "Guaranteed timelines quoted before anyone has understood the problem, fixed bids dramatically lower than every other quote, vagueness about who actually does the work, contracts that are unclear about IP ownership, a portfolio you cannot verify or use, and a partner who says yes to everything without ever pushing back on scope." } }, { "@type": "Question", "name": "How do good software partners estimate projects?", "acceptedAnswer": { "@type": "Answer", "text": "Good partners estimate in ranges, explain their assumptions, and narrow the range as unknowns are resolved — often by proposing a small paid discovery or first milestone before committing to the whole build. Precision offered before understanding is a sales tactic, not an estimate." } } ] }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://tetracorehq.com/" }, { "@type": "ListItem", "position": 2, "name": "Insights", "item": "https://tetracorehq.com/insights" }, { "@type": "ListItem", "position": 3, "name": "How to Choose a Custom Software Development Partner: A 12-Point Checklist", "item": "https://tetracorehq.com/insights/how-to-choose-software-development-partner" } ] } ] --- [![TetraCore Logo](/lovable-uploads/f8ea3e1f-4668-4dc0-aedd-6bfcdfc60d00.png)TetraCore ](/) [Home](/) [Products](/products) [Services](/services)[About](/about)[Insights](/insights)[Support](/support)[Start a Project](/contact) [All Insights](/insights) # How to Choose a Custom Software Development Partner: A 12-Point Checklist By W. Miller, TetraCore July 9, 2026 9 min read Hiring a software development partner is one of the most expensive decisions a non-technical buyer ever makes, and most of the advice about it is written by the vendors themselves. This checklist tries to be the exception: twelve things worth verifying before you sign, useful whoever you end up hiring — including nobody. None of these items require you to be technical. They require you to ask direct questions and pay attention to how directly they get answered. 1. ## 1. Shipped products you can actually try Screenshots and case-study PDFs are marketing; a live product is evidence. Ask for something the partner has built that you can sign up for, click through, and break. If they build for clients only, ask for a client build you can at least demo. A team with nothing usable to show is asking you to be the first verification of their work. 2. ## 2. Who actually writes the code Many firms sell you their senior people and deliver subcontractors. Ask directly: who will be in the repository day to day? Where are they? Are they employees? Will the people in the sales meeting appear in the standups? Subcontracting is not automatically bad, but undisclosed subcontracting tells you how the rest of the relationship will go. 3. ## 3. A real security posture Ask how they handle secrets, access control, dependency updates, and vulnerability reports — in their own products, not hypothetically. A partner that can't describe its own security practices in concrete terms will not invent good ones for your project. 4. ## 4. Source-code and IP ownership, in writing You should own the code you pay for, full stop — repository access from day one, not a zip file at the end. Read the IP clause before you sign. Watch for licenses back to the vendor, "reusable components" carve-outs broad enough to swallow the project, and anything that makes leaving expensive. 5. ## 5. A plan for post-launch operations Software is not finished at launch; it is merely started. Who monitors it? Who gets paged? Who applies security patches and pays the cloud bill? A good partner raises this before you do. If the engagement model ends at handoff, make sure you have a team ready to catch what gets handed off. 6. ## 6. Communication cadence you can live with Agree upfront on the rhythm: how often you see working software (not slide decks), who your direct contact is, and how quickly questions get answered. The best predictor is the sales process itself — a partner who is slow and vague before you sign will not speed up after. 7. ## 7. References from comparable projects Ask for references from projects of similar size, stack, and stakes — then actually call them. Two questions matter most: "What went wrong, and how did they handle it?" and "Would you hire them again?" Every project has problems; you are hiring for how they behave when problems arrive. 8. ## 8. How they scope and estimate Good partners estimate in ranges, state their assumptions, and propose a small first milestone or paid discovery to shrink the unknowns. Be suspicious of precision that arrives before understanding: a to-the-day timeline quoted in the first meeting is a number invented to win the deal. 9. ## 9. Willingness to say no Somewhere in the process, a good partner should push back — on a feature that adds risk without value, a deadline that guarantees corner-cutting, or a build-it-all-at-once plan that should be staged. A vendor who agrees with everything is not aligned with you; they are avoiding friction until the contract is signed. 10. ## 10. Sensible technology choices, explained Ask why they recommend the stack they recommend. The right answer connects choices to your team, your hiring market, and boring long-term maintainability. The wrong answer is whatever is newest — resume-driven development is a real cost that lands on you years after the vendor is gone. 11. ## 11. Documentation and handoff quality Ask to see documentation from a past project: a README that gets a new engineer running locally, deployment runbooks, architecture notes. If another competent team cannot pick the project up, you do not own working software — you own a dependency on one vendor. 12. ## 12. Transparent, predictable pricing However the engagement is priced — time and materials, fixed bid, retainer — you should be able to predict your invoice. Ask what happens when scope changes and what a change order costs. The red flag is not any particular model; it is a model you cannot explain back to your own finance team. ## How to run the checklist without being technical A checklist is only as good as the process wrapped around it, so here is the process we would use ourselves. Shortlist three candidates, not ten — past three, the quality of your evaluation drops faster than the quality of your options improves. Send every candidate the same questions in writing before you take a single demo call: written answers can be compared side by side, while live answers are mostly a measure of who is charming, and charm is not a deliverable. Score the answers simply — zero for evasive, one for partial, two for direct with evidence — and double-weight the two items that cause the most expensive failures: source-code ownership and post-launch operations. A vendor can be mediocre at communication cadence and you will merely be annoyed; a vendor who is vague about IP or has no answer for who carries the pager will cost you the project. Then, whoever wins the scoring, do not award the whole build. Award a small first milestone — a paid discovery, a single feature, something with a real deliverable inside a month or so. The checklist tells you who deserves the test; the milestone is the test. Every point on this list is cheap to fake in a proposal and expensive to fake in a working repository you have access to. ## What a good answer actually sounds like Take item five, post-launch operations, since it is the one buyers skip most. A weak answer sounds like: "We offer flexible maintenance packages." That is a price sheet, not a plan. A strong answer names mechanics: what monitoring gets wired in before launch and who receives the alert at 2 a.m.; how security patches are applied and on what cadence; what the handoff includes if you ever leave; which cloud account the software runs in and who pays the bill. You do not need to be technical to hear the difference — one answer is about their offering, the other is about your software. We can say what our own answer looks like, since we have to give one too: every build we operate is wired into uptime monitoring from day one — ours happen to run on [FourSight](/products/foursight), the monitoring product we built and depend on ourselves — and credentials change hands through expiring one-time secret links (we use our own [LinkPilot](/products/linkpilot) for this) rather than sitting in email threads forever. The specifics matter less than the pattern: a partner who operates software has reflexive, concrete answers, because the answers describe what they already do rather than what they would hypothetically offer. Item one works the same way. "Shipped products you can try" does not just prove technical competence — it shows you how the partner behaves as an owner: how they write a pricing page, how they disclose limitations, how they handle a status incident. And the strongest version of the signal is domain immersion. Our chain-of-custody product [ItemStage](/itemstage) was developed in cooperation with Millers Restoration, inside a working restoration facility, and it shows in what got built: the unglamorous features that only matter when trucks are actually arriving. Ask any candidate where their understanding of your domain will come from. "We will learn it during discovery" is an honest answer; whether it is a sufficient one depends on how much your domain punishes ignorance. ## Which points you can relax — and which you cannot Honesty requires saying that the twelve points are not equally rigid, and a dogmatic reading will disqualify some perfectly good partners. Two are non-negotiable in our view: source-code and IP ownership (item four), because everything else can be renegotiated later and this one cannot, and knowing who writes the code (item two), because every other answer you were given is worthless if a different team shows up. Several others can be relaxed with your eyes open. A newer firm may not have a deep reference bench (item seven) — substitute a smaller first milestone and treat it as the reference. If you already run an internal engineering or ops team that will own the result, the post-launch plan (item five) can legitimately be "we hand off to your people," provided the handoff quality (item eleven) is real. And the pricing model (item twelve) genuinely does not matter as long as you can predict the invoice — we publish flat pricing on our own products and still think time-and-materials is the honest model for some kinds of client work. What you should never do is relax a point because the vendor was likable, the deadline is close, or the price was surprisingly low. Those are the three conditions under which almost every bad software engagement gets signed. ## The pattern behind the twelve points Every item on this list is a version of the same test: **does the partner behave, before the contract, the way you need them to behave after it?** Evidence over promises. Specifics over adjectives. Pushback over flattery. A vendor who passes that test with a small first milestone has earned a bigger one; a vendor who fails it in the sales process will not improve once the invoices start. Take the list into every conversation, and hold every candidate to it equally. ## Disclosure This checklist is published by TetraCore, an Ohio software studio that builds custom software and operates [six SaaS products of its own](/products). We obviously hope we pass these twelve points — and we would rather you apply them to us and everyone else than hire anyone, including us, without asking. If you want to run the checklist against our [services](/services) or read [about the studio](/about), everything is on this site. ## Frequently asked questions ### What should I look for in a custom software development partner? Look for evidence over promises: shipped products you can actually try, clarity about who writes the code, a real security posture, unambiguous source-code ownership in the contract, a plan for post-launch operations, and references from projects that resemble yours in size and shape. ### What are red flags when hiring a software development company? Guaranteed timelines quoted before anyone has understood the problem, fixed bids dramatically lower than every other quote, vagueness about who actually does the work, contracts that are unclear about IP ownership, a portfolio you cannot verify or use, and a partner who says yes to everything without ever pushing back on scope. ### How do good software partners estimate projects? Good partners estimate in ranges, explain their assumptions, and narrow the range as unknowns are resolved — often by proposing a small paid discovery or first milestone before committing to the whole build. Precision offered before understanding is a sales tactic, not an estimate. ![TetraCore Logo](/lovable-uploads/f8ea3e1f-4668-4dc0-aedd-6bfcdfc60d00.png)TetraCore ## Company - [Home](/) - [About](/about) - [Products](/products) - [Services](/services) - [Insights](/insights) - [Careers](/careers) - [Contact](/contact) - [Support](/support) ## Products - [FourSight](/products/foursight) - [LinkPilot](/products/linkpilot) - [VoterCXM](/products/votercxm) - [ItemStage](/itemstage) - [Franexis](/franexis) - [CallsAround](/callsaround) ## VoterCXM - [State Parties](/products/votercxm/state-parties) - [County Parties](/products/votercxm/county-parties) - [PACs](/products/votercxm/pacs) - [Voter Outreach](/products/votercxm/voter-outreach) ## Trust & Legal - [Privacy Policy](/privacy) - [Terms of Use](/terms) - [ItemStage Security](/itemstage/security) - [ItemStage Privacy](/itemstage/privacy) - [Franexis Security](/franexis/security) - [Franexis Privacy](/franexis/privacy) © 2026 TetraCore. All rights reserved. TetraCore — the Ohio software studio. Not affiliated with Tetracore, Inc. (biotechnology). Empowering your digital future through AI-powered innovation. Software Solutions Systems Security