Software development firm vs. consulting firm: Which kind of partner does your roadmap need?

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.

Start with the constraint, not the vendor label

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.

A decision matrix for engineering leaders

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.

What a software development firm should own

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.

What a consulting firm should own

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.

When a blended partner makes sense

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.

How an existing-codebase takeover should begin

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.

• Map ownership. Identify who can approve product behavior, architecture changes, production access, and releases. Name the internal person who resolves conflicting requirements.
• Reproduce the highest-value problems. A backlog label is not evidence. Reproduce bugs, trace affected workflows, inspect logs, and confirm which items are still relevant.
• Trace the delivery path. Document how a change moves from branch to production, which tests run, who approves a release, and how rollback works.
• Find the unsafe unknowns. Look for unowned services, expiring credentials, manual data repairs, undocumented device behavior, brittle third-party integrations, and missing observability.
• Establish a first delivery slice. Choose work valuable enough to matter and bounded enough to reveal how the teams collaborate. The goal is evidence about delivery, not a throwaway demo.

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.

Governance should expose decisions and delivery

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.

Reference diligence that tells you something

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.

Match the commercial lane to the work

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.

Red flags in either kind of proposal

• The delivery team is unnamed, or the named senior people have no committed capacity.
• The plan promises a transformation outcome without access to the systems and people that determine it.
• The vendor quotes a legacy takeover before inspecting the repository, production path, and incident history.
• Governance describes meetings but not decision rights, acceptance, escalation, or release authority.
• The buyer cannot retain the code, documentation, environments, and operational access needed to change partners.
• The reference is impressive but cannot discuss work similar to the proposed engagement.
• The proposal treats security, QA, deployment, and handoff as optional items to define after development.

A 30-minute selection exercise

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.

Where Horizon Labs fits

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.

Sources used

• NIST SP 800-218: Secure Software Development Framework
• UK National Cyber Security Centre: Supplier assurance questions
• Google Cloud DORA research program

Frequently asked questions

What is the difference between a software development firm and a consulting firm?

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.

Which kind of firm should we hire to clear an existing engineering backlog?

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.

Can one partner advise and implement without creating a conflict?

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.

What should we ask during reference checks?

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.

How much does Horizon Labs charge?

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.