Blog · 13-min read
Software development firm vs. consulting firm: Which kind of partner does your roadmap need?
Skip to content
Last substantive review: August 2026.
If your roadmap is stuck, the distinction between a software development firm and a consulting firm matters less than the reason it is stuck. A company that already knows which customer workflow needs to ship may need experienced builders. A company with six competing transformation programs and no agreed technical direction may need an advisory team first. Both vendors can use the same words in a proposal: strategy, innovation, delivery, transformation. The useful question is what they will be accountable for after the kickoff.
A software development firm should turn an agreed priority into working, supported software. A consulting firm should help leadership make consequential decisions about operating models, portfolios, processes, architecture direction, or investment. Some partners can do both, but the proposal should still separate the advisory decisions from the implementation work. If it does not, you cannot tell what you are buying or how to judge progress.
Before comparing logos, write one sentence that names the constraint. Examples include: We have an approved roadmap but not enough senior engineers to execute it. We inherited a product whose backlog keeps growing because nobody understands the riskiest parts of the codebase. We need an executive decision on whether to replace, buy, or modernize three internal systems. We need specialist embedded, IoT, platform, or AI experience that our team does not have. We need a complete product team to take one release from design through launch.
That sentence is more useful than a request for a full-service digital partner. It tells you whether the next deliverable should be a decision, a plan, or production software. It also gives references something concrete to confirm.
| Your immediate need | Best starting partner | What you should receive | What to watch for |
|---|---|---|---|
| A prioritized backlog needs to ship | Software development firm | Named engineers, an execution plan, tested increments, release support, and clear ownership | A generic discovery engagement that delays work your team already understands |
| Leadership has not agreed what to fund or change | Consulting firm | Decision criteria, current-state evidence, options, costs, risks, and an accountable recommendation | A transformation deck with no decision owner or implementation path |
| An inherited system is blocking releases | Senior development specialists, with a short diagnostic phase | A codebase and production assessment followed by fixes, modernization, or backlog delivery | A fixed estimate issued before anyone has inspected the repository, telemetry, and deployment path |
| A net-new product or major feature needs one accountable team | Product development team | Product clarification, design, full-stack engineering, QA, launch, and post-launch warranty | Separate design and engineering teams that hand work across an unmanaged boundary |
| A regulated or company-wide transformation changes process, technology, and governance | Consulting lead plus implementation capacity | An operating decision, phased roadmap, control model, and staffed delivery plan | Advice that assumes execution capacity will appear later |
| A narrow embedded, IoT, AI, or platform problem needs speed | Senior specialist engineers | Direct access to people who have solved adjacent technical problems and can work inside the current system | A large blended team where the specialists are reviewers rather than hands-on contributors |
The matrix is a starting point. A company may move from one column to another as uncertainty falls. A bounded diagnostic can turn a well-scoped inherited-system problem into a build plan; the time needed depends on access, system size, and the unknowns uncovered. A consulting recommendation can expose a capacity gap that needs an implementation team. The mistake is buying months of one kind of work when the next decision requires the other.
A build partner earns its place by reducing the distance between an approved priority and reliable software. That normally includes architecture decisions close to the work, implementation, code review, testing, deployment, documentation, and operational follow-through. Product judgment still matters, but it should be tied to choices the team can implement.
Ask who will be assigned before you sign. You should know the delivery lead, the people writing and reviewing code, the QA owner, and any part-time specialist. A senior person who only appears in sales meetings is not assigned capacity. If the work depends on embedded firmware, Kubernetes, payments, or production AI, confirm how many hours the named specialist will spend in the codebase and who covers the work when that person is unavailable.
A good development firm can also challenge a weak requirement. That is not the same as selling an open-ended strategy program. It means an engineer can explain why a proposed integration creates a data-consistency risk, a product lead can narrow a release to its valuable path, and the team can show the cost of each option. Advice is strongest when it is connected to code, tests, and production constraints.
Consulting is the right purchase when the main output is an organizational decision. That may include choosing a target operating model, rationalizing a technology portfolio, building an investment case, defining governance across business units, or comparing a software purchase with a custom build. The work often involves stakeholder interviews, financial modeling, process analysis, and executive facilitation before a build is sensible.
Judge consulting work by the decisions it makes possible. A useful recommendation names the evidence, assumptions, options considered, tradeoffs, decision owner, and next action. It should also state what the team could not verify. If the final deck recommends modernization without mapping the affected systems, owners, dependencies, and implementation capacity, the hard part has merely been moved to a later contract.
Do not ask a pure advisory team to absorb delivery risk it was not staffed to own. Conversely, do not ask a build team to settle a portfolio dispute that executives have avoided. Both arrangements create motion without authority.
One partner can advise and build when the boundary is explicit. The engagement might start with an architecture and backlog diagnostic, end that phase with a written decision, and then move the approved work into delivery. The people making the recommendation should remain available during implementation so that a new team does not have to rediscover every constraint.
A blended partner is especially useful when technical discovery will change the recommendation. Existing-codebase modernization is a common example. Repository history, production telemetry, deployment scripts, data contracts, and unresolved incidents often matter more than an executive description of the system. Senior engineers need to inspect those facts before anyone can responsibly choose between repair, replacement, or staged extraction.
There is a conflict to manage: a partner that advises on the work may benefit from recommending more implementation. Make the decision gate visible. Require alternatives, including a smaller path and a path your internal team can own. Let the buyer approve each phase separately. Good governance makes the blended model easier to trust.
Backlog-clearing work needs more than adding anonymous capacity. Whether the commercial model is staff augmentation or a managed engagement, the named senior engineers need enough context and authority to make progress without destabilizing production. The first phase should produce an operating picture, not a ceremonial audit.
MKProducts is a relevant Horizon Labs example because the work required continuity inside a real technical backlog. The client worked with Horizon from November 2024 through at least July 2026 on Android and embedded orbital-welding software, including USB behavior, kiosk workflows, weld logs, and device debugging. The useful proof is the duration and technical surface area. No quantitative speed or reliability result is being claimed.
A weekly status call is not a governance model. The buyer needs a small set of artifacts that show what changed, what is blocked, and who can unblock it. For most engagements, that means a prioritized backlog, a current release plan, short architecture decision records, a dependency and risk log, a demo of working software, and a production-readiness view.
Track measures that match the constraint. If the goal is to clear a backlog, look at accepted work, aging blocked items, escaped defects, and whether the team is reducing or creating operational risk. For a platform team, deployment frequency, lead time for changes, change failure rate, and time to restore service can provide a system-level view. These delivery measures are used in Google's DORA research program; do not turn them into individual developer scorecards.
Security requirements also belong in the operating model. The NIST Secure Software Development Framework gives software acquirers and suppliers a common vocabulary for secure development practices. A proposal does not need to reproduce the standard, but it should say who owns security requirements, reviews, vulnerability handling, third-party components, and evidence.
References are most useful when their work resembles yours in operating conditions, not just industry. Ask for a client whose team inherited an existing codebase if that is your situation. If the work is a launch, ask for someone who saw the release and warranty period. If it is embedded or AI work, speak with the person who could judge technical depth.
The UK's National Cyber Security Centre supplier-assurance questions cover governance, incident recovery, data, personnel, offshoring, and independent assurance. They are a good prompt, but evidence remains point-in-time. Ask how the proposed delivery team behaves now, not only what policy the company wrote.
Useful reference questions are plain: Were the people presented in sales the people who did the work? How did the team respond when an assumption failed? Could your engineers review and operate the code? What happened during a difficult release? Did the partner surface risks early? What work was inside and outside post-launch support? Would you hire the same team for this kind of problem again?
Rarewaters offers a different kind of continuity reference. Horizon worked with its Sharetribe marketplace from the first day of marketplace operations through acquisition. That timeline should not be read as a claim that Horizon caused the acquisition. It does mean the client can speak to a long operating relationship across more than one project phase.
Horizon Labs uses two practical lanes. The $100–120 per hour product-team lane is for a company that needs coordinated full-stack engineering, QA, launch support, and a six-month code warranty. The signed statement of work controls the warranty's exact coverage and exclusions. This lane fits a net-new product, a defined release, or a sequence of features where one team should own the path from product clarification through production.
The $150–200 per hour senior-specialist lane is for work where experience and speed carry more weight than team breadth: taking over a difficult backlog, debugging embedded or IoT systems, production AI engineering, platform modernization, or a risky integration. These engagements are often smaller in headcount and heavier in senior hands-on work.
Hourly price alone will not tell you which is cheaper. Compare the assigned team, the work it can own without handoffs, the expected decision latency, and the cost of a failed release. Ask for the commercial assumptions in writing: staffing, weekly capacity, meeting load, environments, client responsibilities, warranty boundary, and how priorities can change.
Bring the internal sponsor, the engineering owner, and whoever controls the budget into one room. Write the constraint, the first decision or release that would prove progress, and the evidence you expect within 30 days. Then score each vendor on five questions: Are the accountable people named? Have they done adjacent work? Can they explain the first operating risk without theater? Does the governance model show who decides? Can the contract expand, narrow, or stop at a clean boundary?
If your answer is still between consulting and development, buy the smallest phase that resolves the uncertainty. That may be an executive options assessment, a codebase diagnostic, or a bounded product milestone. Do not sign a multi-quarter program to discover which problem you have.
Horizon is a build-led product and engineering partner. We can help shape a release or diagnose an inherited system, but our strongest fit is a company that wants senior people to stay close to implementation and own working software. Read the staff augmentation vs. managed services guide if you are deciding how much delivery ownership to delegate, or compare the evaluation criteria in our mid-sized-company partner guide.
If the constraint is a backlog, specialist gap, or release that needs a named senior team, contact Horizon Labs with the current codebase, product surface, and timing. We will tell you whether the first sensible step is a product-team milestone, a senior-specialist diagnostic, or work your internal team should keep.
A software development firm is accountable for designing, building, testing, and releasing working software. A consulting firm is usually accountable for analysis and decisions about strategy, process, operating model, investment, or transformation. Some firms do both, but the proposal should separate advisory outputs from implementation ownership.
Choose a development partner with senior engineers who can inspect the current codebase, production path, telemetry, and backlog before committing to a plan. If the backlog reflects unresolved portfolio or operating-model decisions, a short advisory phase may be needed first, but the team clearing it should still own implementation.
Yes, if the engagement has explicit decision gates, documented alternatives, and separate approval for implementation. The people who advise should remain available during delivery, while the buyer keeps the right to choose a smaller path, use its internal team, or stop after the advisory phase.
Ask whether the proposed people did the work, how the team handled a failed assumption or difficult release, whether the client could review and operate the code, how risks were communicated, what the warranty covered, and whether the reference would hire the same team for a similar problem.
Horizon Labs typically prices coordinated product teams at $100–120 per hour and senior-specialist engineering at $150–200 per hour. The product-team lane includes full-stack delivery, QA, launch support, and a six-month code warranty, with exact warranty coverage and exclusions controlled by the signed statement of work. The specialist lane is designed for difficult backlogs and work such as embedded, IoT, AI, integration, or platform engineering.
Compare 10 software development companies for mid-sized businesses by existing-codebase fit, senior expertise, delivery controls, IP terms, and support.
A decision guide for choosing custom software, commercial products, or targeted modernization, and matching the work to the right senior team.
A CTO’s guide to lifecycle ownership, governance, integrations, release controls, warranty, and a handoff the internal team can operate.
Tell us what you're building. After an intro call with our founders, you'll hear back within 72 business hours: a written scope with an hour range and a hard ceiling, or the questions we need answered first.