The business software works, but every change starts from zero. An integration breaks, someone has to explain the rules again, and the agency sends another proposal. When that work keeps repeating, the question is no longer only who can deliver the next screen. It is what kind of responsibility the business is buying.

An agency usually fits a project with a clear result, scope, and acceptance point. An ongoing software department fits when the system participates in weekly operations and needs someone to retain context, priorities, access, and maintenance. If the business does not yet have ongoing ownership for the software running the business, include that decision before comparing providers.

This is different from choosing between a freelancer and an agency for a software project. That decision is mainly about who can deliver a bounded piece of work. Here, the question is whether the business needs a relationship that keeps answering for the next change, the next failure, and the handoff to another person.

Diagram comparing a project agency with an ongoing software department and showing who owns the next change.

The short answer

  • Choose an agency when the result can be described, accepted, and closed without a permanent queue of decisions.
  • Consider an ongoing software department when software changes along with sales, service, inventory, billing, or another important operation.
  • In either model, the business should control its accounts, data, and access and know who decides when the work changes shape.
  • Do not buy a promise of proximity. Ask for a verifiable path for maintenance, changes, incidents, and exit.

What is the difference between an agency and an ongoing software department?

An agency organizes people to deliver an agreed result. An ongoing software department organizes responsibility that remains while the software changes. The first relationship may end or change when acceptance happens. The second needs to retain context so each request does not begin with a full investigation.

That does not make an agency inferior or turn an ongoing department into an internal team. The names describe different ways of working. An agency can support a client after a project. An ongoing department can be made up of external professionals. What matters is what the agreement requires someone to monitor and explain.

Compare the models by asking what would be left unanswered if the provider left:

Question Project agency Ongoing department
What are you buying? A delivery with scope and acceptance A prioritized queue of work and care
When is context used? During the project and handoff With every change and operating decision
What happens after launch? A defined support plan or new contract Agreed maintenance, improvement, and follow-through
Who accepts the result? A business-side owner A business-side owner with ongoing support
How does the relationship end? Handoff, export, and closure A documented transition with recoverable accounts and history

The table does not replace a proposal. It keeps the business from comparing a one-time delivery with ongoing responsibility as if they were the same product.

When is an agency enough?

An agency may be enough when the business can describe the problem, provide the necessary decisions, and accept a delivery on a defined date or stage. A new form, an isolated integration, or a bounded migration can fit this model if the operation knows how to verify the result.

Before hiring, turn the proposal into an observable path:

  1. Which real workflow will change?
  2. What is out of scope?
  3. How will the business know the delivery works?
  4. Who decides when an exception appears?
  5. What will another person receive after the handoff?

The checklist for comparing software proposals before signing helps put those questions in the same frame. A proposal that lists technology, hours, and screens but does not explain acceptance, access, and exit does not describe the whole job.

An agency can also stay involved after the project. If it does, do not assume the word support covers everything. Separate a correction, update, question, new feature, incident, and business-rule change. If the business has to decide what support means only after something breaks, the relationship is still being treated like a project.

When does an ongoing software department make sense?

An ongoing department makes sense when the software participates in an operation that does not stop after the first delivery. Rules change, exceptions appear, systems must keep talking, and someone must decide what belongs in the next change. The work can be part-time or external. The responsibility cannot be occasional.

Practical signs that the problem has moved beyond a project include:

  • every request requires retelling the workflow and finding the same accounts;
  • small changes sit in a queue because nobody can prioritize them;
  • an integration matters to the operation, but only one person knows how it works;
  • the provider delivers screens, but nobody follows the result in the real workflow;
  • every new request becomes a separate proposal even when it depends on the same system.

The guide to who maintains software after launch covers access, maintenance, context, and handoff. This article asks an earlier question: does the business only need to finish a delivery, or does it need to buy a way to keep the queue understandable?

NIST's "Building Your Small Business’s Cybersecurity Team: From In-House to Outsourcing" describes options that range from an internal role to an internal team, outside support, or a mix. That page is about cybersecurity, not software development. The principle still helps: the arrangement can vary, but outcomes, responsibilities, and expectations need to be defined.

What should an ongoing department own?

An ongoing department is not a subscription for asking anyone to do anything without priority. It should make the work that keeps the operation running visible, along with the rule used to choose the next change. Otherwise, the business has traded a project provider for an equally confusing queue.

Ask the relationship to explain how it will handle:

  • Context: business rules, integrations, important data, and past decisions.
  • Priority: how a failure, obligation, and improvement enter the queue.
  • Access: accounts, repositories, domains, hosting, and services owned by the business.
  • Maintenance: updates, backups, alerts, incidents, and dependencies that can break.
  • Proof: how the team shows that a change works in the workflow the business uses.
  • Handoff: how another person receives the system, history, and decisions if the relationship ends.

That does not mean the provider should own the business or decide alone what matters. The business remains responsible for its rules and decisions. The team should organize enough technical information for an owner to decide without relying on a private conversation with one professional.

The Federal Trade Commission's cybersecurity guidance for small businesses recommends putting vendor responsibilities in writing, controlling access to data, and clarifying who manages a website after it is built. This is not a development contract, but it gives any ongoing relationship a simple test: what is written down, who verifies it, and how does the business take control back?

How can you choose without buying a vague promise?

Start with the work the business must keep running, not the provider's description. An agency may be the right choice for a bounded delivery. An ongoing department may be right for a system that needs recurring decisions. A packaged product or a process correction may be better than either one.

Use this sequence before requesting proposals:

  1. Describe a real week. List what the team does, where it re-enters information, and which failure interrupts the work.
  2. Separate delivery from responsibility. Mark what ends with a version and what will keep changing.
  3. Name the business owner. The provider cannot invent the rules for sales, billing, or service by itself.
  4. Compare the after. Ask who handles a failure, who approves a change, and what costs appear when scope changes.
  5. Test the exit. Ask for accounts in the business's name, recoverable data, documentation, and a handoff another person can perform.

If the main problem is that current tools do not talk to each other, do not turn provider selection into an automatic purchase. The diagnosis of business systems that do not talk to each other helps separate process, data, integration, and responsibility before hiring.

A buying conversation becomes more useful when the provider walks through a real case: a sale that changes, an order that needs correction, an access permission that is revoked, or a failure outside the ideal path. The response shows more than a portfolio presentation. It shows whether the team understood the work it will have to sustain.

What should you ask before signing?

Ask questions the business owner can check later. Answers such as "our team handles that" are incomplete unless they come with a name, an artifact, a deadline, or an acceptance method.

  • Who will do the work after the sale, and who decides when priorities conflict?
  • Which accounts, data, and services are in the business's name from the start?
  • What is included when a business rule changes or an integration stops working?
  • How do you record decisions, dependencies, and important changes?
  • What is the difference between maintenance, an incident, and a new delivery?
  • Who checks the result with the people who use the workflow?
  • What happens if the main person leaves or becomes unavailable?
  • How does the business end the relationship without losing access, history, or the ability to operate?

The software maintenance agreement checklist helps detail scope, response, and exit when the decision is a recurring relationship. The question is not whether the provider promises to stay. It is whether the business can recognize, manage, and replace that responsibility.

Is an ongoing department the same as hiring an employee?

No. Hiring an employee creates an employment relationship with its own management, availability, and obligations. An ongoing department can be external, internal, or mixed. What they share is continuity of work and context, not a legal structure or team size.

A small business does not need to create an internal department just because software matters. It also should not call a one-time delivery a department to hide the fact that nobody will maintain it. The model should fit the queue, risk, decision capacity, and level of follow-through the operation can provide.

Is an agency wrong when software changes constantly?

No. An agency can work when the contract and operating model cover continuous change. Some agencies keep clients for years. In that case, evaluate them by the same criteria as an ongoing department: preserved context, priorities, access, maintenance, proof, and exit.

The provider's name does not guarantee continuity. A small team can be careful, and a large agency can leave work without a clear owner. Ask for evidence of the process used after the first version is in production and the next request no longer fits the original proposal.

Should the business give the provider control of its accounts?

No. A provider can administer the work without being the sole owner of the domain, hosting, repository, data, or recovery methods. Access should be individual, limited to what the work needs, and revocable when the role changes.

The FTC recommends limiting vendor access to what the vendor needs and recording in the contract how data will be handled. That protects the operation without preventing an external team from doing its job. The business should still be able to log in, check, export, and transfer what it bought.

Conclusion

Choose an agency when the business has a clear delivery, an acceptance method, and a realistic way to receive the handoff. Consider an ongoing software department when the software keeps changing with the operation and someone must retain context, organize priorities, and answer for the next decision.

In either model, the business should keep accounts, data, decisions, and a verifiable exit under its control. The difference is the shape of responsibility after the first delivery. If the system already supports daily work and nobody can say who owns the next change, that is the buying problem to solve first.

How this article was produced

Samuel Fajreldines is responsible for this article. The research combined NIST and FTC guidance on outside support, access, vendors, and responsibility; decision pages already published on this site; current search results in English, Portuguese, and Spanish; and recent public discussions by small-business owners. Those discussions help name objections, but they do not measure how common a problem is or prove a provider's quality.

This article does not present a client, price, timeline, benchmark, or private result as personal experience. AI assistance supported discovery, the first draft, image generation, localization, and consistency review. It did not test providers, access a client operation, or replace source verification.

Sources consulted