Software Development for Small Business: How Small Business Software Development Works, What It Costs and When It Pays

Updated October 2026 · Written and maintained by the Progression Agency strategy team

Small business software development is the design and build of custom software, mobile apps and integrations for companies with a handful of people, where the tools sold to everyone no longer fit how the business actually runs. It is for owners and operations leads who have outgrown spreadsheets and copy-and-paste between systems, and it produces the specific thing they lack: a quoting tool, a client portal, a field app, or the connection that stops staff typing the same order into three places. Progression Agency is based in New York City and works with clients across the United States and worldwide.

What is small business software development?

It is custom development scoped for a company where the owner, not an IT department, signs off on the software and lives with the result. The work ranges from one integration between two tools to a customer app, and the defining constraint is that a small team has to be able to run what gets built.

Custom work sized for a team of a few people

Large companies commission software to replace whole departments’ systems. A small business usually needs something narrower: one workflow no product handles, one connection between products that do not share data, or one customer-facing tool that sets the business apart. The craft is the same as any software project (discovery, design, build, testing and support), but the scope is cut to what a small team can adopt in weeks and maintain for years without hiring an engineer.

Who commissions it

Owners of service firms, trades businesses, practices, shops and distributors, usually after years of making do with a stack of subscriptions. The person asking is rarely technical. They know the process in detail, they know where time and money leak, and they need a developer who will turn that knowledge into software without turning the project into an IT program that the business cannot staff.

What it is not

It is not a replacement for accounting, payroll, email or payment software, which are better bought than built. It is not a website redesign, although a site and a portal are often planned together; our web development services page covers the site side. And it is not a reason to rebuild a product that already does the job. A good developer’s first question is whether something you can buy, configure or connect will do.

Why very small firms are a distinct case

The SBA Office of Advocacy counts 36,207,130 small businesses in the United States in its 2026 frequently asked questions about small business, and 82.3 percent of them, about 29.8 million firms, have no employees. Only 17.7 percent, about 6.4 million, have paid staff. Advocacy generally defines a small business for research purposes as an independent business with fewer than 500 employees, so the category runs from a sole owner to a sizable company. Software for a firm of one to twenty people has to be simpler to run, cheaper to host and easier to hand over than software written for a company with its own IT team, and that changes almost every decision in the project.

Signs your business has outgrown off-the-shelf tools

The clearest sign is people doing work the software should do: typing, checking, copying and reconciling. Each sign below is cheap to measure before you speak to a developer, and the measurements become the business case for the project.

The same data is typed into two systems

An order is entered in the online store, then again in the accounting package, then again in a shipping tool. Every re-entry costs minutes and creates a chance for a typo a customer will notice. Count the re-keyed records in a normal week and the minutes each one takes; that count is usually the first thing an integration removes, and it is the easiest saving to prove afterward.

A spreadsheet has become the system of record

Spreadsheets are excellent until several people edit the same one, it holds customer data, and nobody is sure which copy is current. When a spreadsheet decides what gets shipped, billed or scheduled, it has become software without the safeguards: no permissions, no reliable history, no validation of what people type. That is the moment to consider a small database application in its place.

Subscription fees grow faster than the team

Per-seat pricing is fair at five users and painful at forty, especially when most seats use one screen. Add up what you pay each year for tools that overlap or that you use a tenth of. Our custom software versus off-the-shelf guide works through a five-year comparison; for most small firms the answer is still to keep buying, but the total is worth knowing before anyone quotes a build.

A workflow no product supports

Some processes are the business itself: how you price a custom job, how you schedule crews around inspections, how you track a client’s file through review. When every product forces a workaround, the workaround becomes a hidden cost that grows with every new hire who has to learn it, and it is where custom software most often earns its price.

Customers ask to do things themselves

Clients who want to check status, upload documents, reorder or pay without calling are telling you something. Answering the same status question by phone many times a day is a sign that a portal or a simple app could pay for itself in staff time, and it is often what customers mean when they say a competitor is easier to deal with.

Reports are assembled by hand

If the monthly numbers take a day of exports and pivot tables, the data exists but is scattered. A dashboard that reads from the systems you already use is often a small project with a quick return, and it tends to expose data-quality problems that are worth fixing anyway.

One person holds the whole process

When a single employee is the only one who knows how a process works, the business carries a risk that software can reduce. Writing the process down for a developer is useful even if nothing gets built, because it is also the training manual the business never had.

How does company size change a small business software project?

Size changes who uses the software, who owns it inside the business and how much of it should be custom. A sole owner and a firm of eighty people both count as small businesses, but they need very different projects.

The owner working alone

Most US small businesses have no employees at all, according to the SBA figures above. For them, custom code is rarely the answer. Templates, a well-chosen booking or invoicing product and one or two automations between tools usually remove the repetitive work at a fraction of the cost. The exception is an owner whose product is itself software, or whose method is unusual enough that no product fits.

Two to ten people

Shared systems start to matter: everyone needs the same customer list, the same job status and the same calendar. The first project is usually an integration or a small internal tool, and the owner is still the person who decides how the process should work. Keep the first release narrow enough that the owner can test it personally.

Ten to fifty people

Work now crosses roles, so permissions, approvals and reporting come into scope. A client portal, a dashboard or a field app often appears here. Somebody inside the business, even part time, should own the systems: the person who knows every tool’s settings and who the developer can ask when a question comes up mid-build.

Fifty people and more

Several departments, more data and more integrations make projects resemble mid-market software work. An internal product owner becomes essential, and an in-house developer may make sense alongside an outside team. Our enterprise app development page covers the larger end of that range.

Name an internal owner at every size

Software without an owner inside the business drifts: nobody approves changes, nobody notices when an integration fails, nobody trains the new hire. Even in a five-person firm, write down who owns each system and who can make decisions about it.

Buy, configure, connect or build: four routes to try in order

There are four ways to close a gap in a small company’s software, and they should be tried in this order, because building costs the most to start and to keep. Our guide to custom software versus off-the-shelf goes deeper into the build-or-buy decision and its five-year costs; this section is the short version for small firms.

Buy: use the product as it comes

For accounting, payroll, email, file storage, payments and most industry basics, a mainstream product is cheaper, safer and better supported than anything a small firm could commission. The trade-off is that you adapt to its way of working, which is usually a fair price for software that someone else keeps secure and current.

Configure: settings, templates and add-ons

Many gaps close inside tools you already own: custom fields, approval rules, templates, an add-on from the product’s own marketplace. Ask the vendor’s support team before you assume something is impossible; configuration costs hours rather than months, and it keeps you on the vendor’s upgrade path.

Connect: move data between tools automatically

When two good products do not share data, an integration moves it between them: a paid order creates an invoice, a signed quote creates a job, a new client creates a folder. Simple connections can run on an automation tool; heavier ones need code, which the integrations section below explains.

Low-code and no-code builders

Visual builders let a non-developer assemble forms, databases and simple apps. They suit internal tools with a few users and a simple data model. Before you commit, check per-user pricing at the size you expect to reach, what you can export if you leave, and whether the logic will make sense to anyone other than the person who built it.

Build: custom software for the part that is yours

Build when the process is how you compete, no product handles it, and the volume justifies the cost. Even then, build only that part and connect it to bought tools for everything else. Progression’s software development company page puts it the same way: where a standard tool already fits, use it and integrate it.

When should a small business not build software at all?

Sometimes the honest answer is not to build. Custom software is a long-term commitment, and some situations make it the wrong answer even when the frustration with current tools is real.

When the process is still changing

If the way you price, schedule or deliver is still being worked out, software will freeze a process that should keep moving. Run it on flexible tools until it settles, write down what stays the same for a few months, and build then.

When the volume is too low

Automating a task that happens twice a month rarely pays back a five-figure build. Compare the hours saved each year, at a fair hourly cost, with the build and running costs over three years before going further.

When a product is about to catch up

Vendors add features regularly. If the product you already use has the missing feature on its published roadmap, or a marketplace add-on covers most of it, waiting or configuring may beat building.

When nobody can own it

Software needs someone inside the business who approves changes, notices problems and trains new staff. If nobody has the time, fix that first; a well-built tool with no owner decays quickly.

When the budget covers the build but not the upkeep

If the business can afford the launch but not maintenance, hosting and support for the years after, the software will age into a risk. Plan the three-year cost or choose a smaller first release that the budget can sustain.

Custom software development for small business: what usually gets built

Most small business builds fall into a handful of patterns. Each replaces a specific manual job, and naming that job is the start of a good brief.

Quoting and estimating tools

A quoting tool turns your pricing method into a form: measurements or options in, a priced and branded quote out, saved against the customer and ready to convert into a job. It suits trades, fabricators and service firms whose prices depend on more than a price list. The return shows up as faster quotes, consistent margins and fewer pricing mistakes.

Client portals

A portal gives each client a login to see status, documents, invoices and messages in one place. Accounting firms, agencies, contractors and property managers use them to cut status calls and email attachments. Our web portal development page covers what a portal includes, from roles and permissions to integrations and security; for a small firm the first version is often three screens: status, documents and messages.

Scheduling, dispatch and field apps

Crews and technicians need the day’s jobs, addresses, notes, photos and checklists on a phone, and the office needs to see what was done without calling. A field app often has to work without a signal and sync later, which matters in basements, rural sites and large buildings, and which is one reason generic tools fall short.

Inventory and ordering

Stock spread across a stockroom, a shop and an online store is a classic integration problem. Our inventory management software development page covers it in depth; for a small seller the first step is usually one trusted count of what is on hand, updated automatically when something sells anywhere.

Internal dashboards

A dashboard pulls numbers from the systems you already use and shows the few that matter, refreshed automatically. See dashboard development for the build itself; the small business version is often a single screen the owner checks each morning: cash, open jobs, overdue invoices and this week’s bookings.

Integrations and data sync

The most common first project in practice: connecting the store to accounting, the CRM to email, the booking tool to the calendar. It removes re-keying without changing how anyone works, which makes it the easiest kind of project for a small team to adopt.

Booking, ordering and payments for customers

A booking flow or ordering page built around your rules, such as deposits, minimums, service areas and lead times, when generic tools cannot express them. Card details should almost always be collected by a payment provider’s hosted fields rather than by your own code, for the reasons set out in the rules section below.

Reading documents with AI

Turning invoices, intake forms and emails into structured records is a task where language models can save real time, provided a person checks the output before it is used. Our AI integration services page covers this work, and the AI section further down covers the questions a small business should ask first.

Small business custom software by industry

The patterns repeat across sectors, but each industry adds its own data, rules and systems. These are typical projects by sector, with links to pages that go deeper.

Trades and home services

Estimating tools that price from measurements, job scheduling across crews, photo checklists that protect against disputes, and integrations that turn an accepted estimate into an invoice. The users work on phones, outdoors and in a hurry, so the interface has to be simpler than anything an office team would accept.

Professional services

Accounting, consulting, design and other advisory firms build client portals, intake forms that feed their practice software, and document workflows with approvals. Tax preparers and some other financial firms fall under the FTC’s Safeguards Rule, which shapes how their software must handle customer information; the rules section below explains when.

Retail and ecommerce

Stock sync between a shop and online channels, custom product configurators, wholesale ordering portals for trade customers, and loyalty tools. Our retail software development and ecommerce app development pages go further into both.

Restaurants and food businesses

Online ordering and catering inquiry flows with the restaurant’s own rules, kitchen display integrations, and loyalty programs that reduce dependence on delivery marketplaces. Our restaurant app development page covers the ordering and loyalty side in detail.

Healthcare and wellness practices

Patient intake, scheduling and reminders, and portals that connect to the practice’s records system. A vendor that creates, receives, keeps or transmits patient information for a practice is generally a business associate under HIPAA, with contract and safeguard duties; see healthcare software development for how those builds differ.

Manufacturing and distribution

Job tracking on the shop floor, quoting for custom work, and ordering portals for dealers or distributors. Our manufacturing software development and logistics software development pages cover the larger versions of these systems.

Real estate and property management

Owner and tenant portals, maintenance request tracking, and listing tools that feed a brokerage’s website. See real estate software development for the systems a growing brokerage or property manager tends to need next.

Education, tutoring and member organizations

Scheduling and billing for lessons, member directories, course access and attendance tracking. Our education software development page covers learning platforms; for a small tutoring business or association, a booking and billing integration is usually the first step.

App development for small business: when a mobile app is worth it

A mobile app earns its cost when customers or staff use it often enough to keep it on their phones. For occasional use, a fast mobile website or a progressive web app usually does the job for less, and mobile app development for small business should start with that comparison.

Customer apps that people keep

Reordering, loyalty, booking and account management are the jobs that bring a customer back weekly or monthly. A one-off purchase rarely justifies an app; a repeat relationship might. Look at how often your best customers buy before you commission one, and at how many of them would install yet another app to do it.

Apps for your own staff

Apps for your team are often the better first investment: the users are known, training is possible, and the return is time saved rather than downloads won. They do not have to compete for attention on a customer’s home screen, and their success is easy to measure in jobs completed and paperwork avoided.

Progressive web apps: an app without the store

A progressive web app runs in the browser, can be added to the home screen and works on any phone, with no store review and no store fees. It cannot reach every device feature a native app can. Our progressive web app development page compares the two approaches.

What the app stores charge

Apple’s App Store Small Business Program cuts its commission to 15 percent on paid apps and in-app purchases for developers with up to $1 million in proceeds in the prior calendar year, and for developers new to the store. The Apple Developer Program costs $99 a year. Google Play charges a one-time $25 registration fee, and its service fees page says 97 percent of developers distribute their apps at no charge. For United States users, Play’s fee on digital sales now depends on whether the user installed the app before or after June 30, 2026 and on the type of transaction, so check the current page before pricing in-app sales.

Physical goods and services use your own payments

Apple’s App Review Guidelines (rule 3.1.3(e)) say an app that sells physical goods or services consumed outside the app must use payment methods other than in-app purchase, such as Apple Pay or card entry. For most small businesses, whose apps sell food, products, appointments or repairs, that means the in-app purchase commission does not apply to those sales; normal card processing fees do.

Review rules that stop thin apps

Guideline 4.2 says an app should include features, content and interface that lift it beyond a repackaged website, and that an app without lasting entertainment value or adequate utility may not be accepted. A small business app needs a real job, such as reordering, booking or account tools, rather than the website in a frame.

Privacy policies and account deletion

Apple requires every app to link to its privacy policy both in App Store Connect and inside the app, and an app that supports account creation must also offer account deletion within the app. Google Play’s account deletion requirements ask for an in-app path to delete an account and its data plus a web link where users can request it. Plan those screens from the first design, not at submission.

How to create an app for a small business, step by step

Seven steps take an app from idea to the stores, and the first three cost little more than time. Skipping them is how small businesses end up paying for an app nobody opens.

Step 1: Write down the one job the app does

One sentence: who opens it, how often, and what they get done. “Regular customers reorder their usual in two taps” is a job. “Our brand on people’s phones” is not. If you cannot write the sentence, the project is not ready, and no developer can price it honestly.

Step 2: Choose a website, a progressive web app or a store app

If customers will use it a few times a year, a fast mobile site is enough. If they will use it often but need no special device features, a progressive web app avoids store fees and review. If it needs device features a browser cannot reach, or customers expect to find it in an app store, a store app is the safer choice.

Step 3: Sketch the screens and the data behind them

List each screen and what it shows, then list the data each screen needs and where that data lives today: the point-of-sale system, the accounting package, a spreadsheet. Most of an app’s cost hides in that second list, because every source of data is an integration.

Step 4: Prototype and test with real customers

A clickable prototype lets five or ten real customers try the flow before anything is built. Published US price bands put a clickable prototype at about $8,000 to $25,000 over three to six weeks, which is cheap next to building the wrong app. Watch where testers hesitate; that is where the design needs work.

Step 5: Build in small releases

Ship the core job first, then add features once people use it. Each release should be something staff or customers can try. Progression’s software page describes working software every two weeks with a short written update, and that rhythm is worth asking any developer about.

Step 6: Set up the store accounts in your company’s name

Apple’s enrollment rules require an organization to be a legal entity, not a trade name, with a D-U-N-S Number, and the organization’s name appears as the seller on the App Store. On Google Play, personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers opted in for 14 days before applying for production access. Register under the business, not the developer, so the listing stays yours.

Step 7: Launch, measure and keep it current

Measure the one job from step 1: reorders placed, bookings made, calls avoided. Then budget for upkeep, because the stores move. Google Play’s target API level requirements say new apps and updates must target Android 16 (API level 36) or higher from August 31, 2026, and existing apps that fall behind stop being offered to new users on newer devices. Wear OS, Automotive OS, TV and XR apps have lower targets, and Google allows an extension request to November 1, 2026.

Integrations: getting the tools you already pay for to share data

An integration is often the best first project for a small business because it removes manual work without asking anyone to learn a new system. The questions are which system owns each piece of data, and whether an automation tool or custom code should move it.

Decide which system is the source of truth

Every record needs one home. Customers might live in the CRM, prices in the store, invoices in accounting. An integration copies data outward from that home and never lets two systems argue about the same field. Writing down the home of each record type is a one-page exercise that prevents most integration failures.

APIs and webhooks in plain terms

An API is the documented way one program asks another for data or tells it to do something. A webhook is a message one system sends automatically when something happens, such as an order being paid. Shopify’s GraphQL Admin API is a typical example of what makes a dependable integration possible: it is documented, versioned by release date and published with rate limits.

Accounting, payments and ecommerce

Orders to invoices, payments to reconciliation, refunds to credit notes: these flows are where re-keying does the most damage, because errors reach customers and tax filings. Use the vendors’ published APIs, keep a log of every record the integration touches, and decide in advance what happens when one side is unavailable.

Email, calendar and documents

Google documents its Workspace developer APIs for Gmail, Calendar, Drive, Docs and Sheets, and Microsoft describes Microsoft Graph as the gateway to data in Microsoft 365. Most small firms run on one of the two, so office automation, such as filing attachments, creating calendar holds from bookings or generating documents from templates, usually starts there.

When an automation tool is enough

Hosted automation tools connect popular apps with triggers and actions and no code. They suit low volumes, simple mappings and flows where an occasional delay does no harm. Our n8n automation page covers one such tool that can also be self-hosted. Watch task-based pricing as volume grows, and keep a list of every automation so nothing runs unowned.

When the integration needs code

Custom code earns its cost when volumes are high, the mapping has business rules, failures must be retried and reported, or a vendor has no suitable connector. Published US price bands put an integration or automation build at about $15,000 to $50,000 over four to ten weeks. Our API development page covers the engineering side.

Single sign-on and user accounts

Once staff use several tools, signing in to each with one company account (single sign-on) makes access easier to grant and, more importantly, to remove when someone leaves. Ask whether new software can use the sign-in your email platform already provides, and keep a list of who has access to what.

How much does small business software development cost?

Published US price bands put a small business software project between about $15,000 for a modest integration and $250,000 for a full client platform, and most first projects sit at the lower end. These are market figures for this work, not a Progression rate card; a quote follows a written scope.

What moves a quote up or down

The number of user types, the number of systems to integrate, data that must be migrated and cleaned, offline use, payments, regulated data and how much of the design is new rather than standard. Fewer screens, one user type and mainstream integrations push a quote toward the bottom of a band; compliance, migrations and real-time features push it up.

Running costs after launch

Software costs money every year it runs. The live app development cost guide puts maintenance and updates at about 15 to 20 percent of the build cost per year and cloud hosting at about $1,200 to $30,000 or more a year, scaling with use, plus usage-based third-party services such as maps, text messages, email and AI. Put those figures in the budget before approving the build.

Fees you pay to others

App store memberships, payment processing, text message and email sending, map lookups, AI model usage and any per-seat licenses the software depends on. They are small at launch and grow with success, so model them at two or three times today’s volume.

Phasing a build to match cash flow

Split the project into releases that each pay back something: the integration that saves hours first, the portal second, the customer app third. Each phase gets its own scope and price, and the business can stop after any of them with working software rather than half a system.

Hourly rates by team type

Most small business projects are quoted as a fixed price for a written scope, but the rates behind the quote explain why quotes differ so much. The live app development cost guide publishes these bands:

App costs by type of small business app

The live app development cost guide also publishes bands by type of app. The rows below are the types small businesses most often ask about; the full guide covers the rest. They are market figures for a complete app, not a Progression rate card.

What individual features add

Features are the easiest place to control an app budget. Each one below is priced separately in the same guide, which makes it simple to see what a nice-to-have really costs before it goes into the first release.

How is small business software billed?

Most small business projects are billed as a fixed price for a written scope, sometimes with time and materials for open-ended work and a monthly plan for support. Each model shifts risk differently, so match the model to how well the work can be defined.

Fixed price for a fixed scope

Suits work that can be written down completely: an integration, an internal tool, a first release. You know the cost up front; the developer carries the risk of estimating. The scope has to be precise, because anything outside it becomes a change request.

Time and materials with a cap

Suits work that cannot be fully defined yet, such as improving an existing system or exploring an integration with a poorly documented vendor. You pay for hours used, which is fair when the path is uncertain, but agree a monthly or phase cap and a weekly report of hours and progress.

A monthly support plan

Covers updates, monitoring, small fixes and a set number of hours or response times each month. It turns maintenance from a series of surprise invoices into a budget line, and it guarantees someone is watching the software.

Paying in milestones

Larger fixed-price projects are usually paid in stages tied to delivered, working releases rather than dates. Tie each payment to something you can use and test, and keep the final payment until acceptance testing is complete.

Know when ownership transfers

Some contracts transfer copyright only on final payment. That can be reasonable, but read the clause: you should receive access to the code throughout the project, and a dispute over one invoice should not leave you without any of the work you have already paid for.

Paying for software: tax rules to raise with your accountant

How software is paid for changes what it really costs. Three federal rules are worth raising before you sign, and each depends on facts only your accountant can weigh; nothing here is tax advice.

Off-the-shelf software and Section 179

IRS Publication 946 treats off-the-shelf computer software as property that qualifies for the Section 179 deduction: software readily available to the general public, licensed on a nonexclusive basis and not substantially modified. For tax years beginning in 2025 the maximum Section 179 deduction is $2,500,000, reduced once qualifying property placed in service passes $4,000,000; for tax years beginning in 2026, Rev. Proc. 2025-32 sets the figures at $2,560,000 and $4,090,000. Subscriptions and custom code follow different rules.

Custom development and the 2025 change for research costs

Section 174A of the tax code, added on July 4, 2025, treats any amount paid or incurred in connection with developing software as a research or experimental expenditure. The IRS’s summary of the new provisions says that for tax years beginning after December 31, 2024, domestic research costs can be deducted in the year paid or incurred, or amortized over at least 60 months by election, while foreign research costs are amortized over 15 years. Where the developers work can therefore change the timing of the deduction; whether and how your contract counts is your accountant’s call.

The research credit and the payroll election

The research credit under section 41 can apply to qualifying development work, but software built mainly for your own internal use qualifies only if it also passes the high-threshold-of-innovation test set out in the IRS’s Form 6765 instructions. A qualified small business may elect to apply part of it against payroll taxes instead of income tax, and the IRS’s page on the payroll election says the cap rose from $250,000 to $500,000 a year for tax years beginning after December 31, 2022. The IRS describes the election as designed to benefit an eligible startup with little or no income tax liability.

Keep records that support the deduction

The IRS’s recordkeeping guidance says good records help you prepare financial statements, keep track of deductible expenses and support items reported on your return. For software, keep the signed scope, invoices, change requests and the developer’s description of what was built and where the work was done.

Budget for the life of the software, not the launch

The tax treatment of the build is a one-time question; maintenance, hosting and support are yearly costs. A project that looks affordable at launch can strain a small budget in year three if nobody planned for upkeep, so ask for a three-year cost estimate, not just a build price.

How long does small business software development take?

Weeks for an integration, a few months for an internal tool, and four to eight months for a client platform, going by the timelines published alongside US price bands. Owner availability for decisions and testing often sets the pace as much as coding does.

Integrations and automations: four to ten weeks

Much of the time goes into mapping fields, agreeing what happens when data does not match, and testing with real records. The coding itself is often the shorter part. A sandbox account from each vendor shortens testing considerably.

Internal tools and dashboards: two to four months

Discovery and design take the first weeks, because internal tools succeed or fail on whether they match how staff work. Building follows in releases, with staff testing each one before it replaces the spreadsheet it is meant to retire.

Portals and customer apps: four months and up

Customer-facing software needs more design, more testing on more devices, accounts and security, and, for store apps, review time. Published bands put a client portal or business platform at four to eight months and a cross-platform mobile app MVP at ten to sixteen weeks.

What stretches a timeline

Late decisions, scope added mid-build, data that turns out messier than expected, vendors slow to grant API access, and testing left to the last week. Each one is avoidable with a written scope and a named person on the business side who can decide quickly.

What a sensible first release includes

The single job that justified the project, working end to end, used by real people. Reports, settings screens and nice-to-have features can follow. A first release that does one thing completely teaches more than one that does five things partly.

Questions to answer before you call a developer

Ten questions, answered honestly, make the first conversation with any developer shorter and the first quote more accurate. None needs technical knowledge.

1. What job takes the most time or causes the most errors today, and how do we know?
2. Who would use the software, how many of them, and on what devices?
3. Which tools do we already pay for, and which would we keep?
4. Have we asked those vendors whether a setting, add-on or connector solves the problem?
5. What data would the software hold, and is any of it card, health, financial or children’s data?
6. What is the smallest first release that would be worth having?
7. Who inside the business will own the software and make decisions quickly?
8. What can we spend on the build, and what each year on upkeep?
9. How will we measure whether it worked, three months after launch?
10. What happens to the business if the software is late by two months?

Write the answers down and send them with your first inquiry. They become the opening of the business requirements document described below, and they let you compare developers on the same basis from the first call.

Business requirements for software development: a brief a developer can quote

A good brief describes the business problem, not the screens. Two pages in plain language let a developer ask the right questions and price the work, and they let you compare quotes on the same basis.

The problem in one paragraph

What takes too long, costs too much or goes wrong, and how you know. Include the numbers you have measured: hours per week, errors per month, calls per day. Numbers make the case for the project and set the target the software will be judged against.

Who uses it and how often

List each kind of user (owner, office staff, field staff, customers), how many of each, what device they use and how often. Ten office users on desktops is a different project from two hundred customers on phones.

The workflow, step by step

Walk through the process as it actually runs today, including the workarounds, then as you want it to run. Developers can price a described workflow far more accurately than a list of features.

Data: what goes in and what comes out

What information is entered, where it comes from, what has to be produced at the end (an invoice, a report, a notification) and how long records must be kept. Mention anything sensitive, such as card numbers, health information or children’s data, because rules attach to each.

Systems it must connect to

Name every tool the software must read from or write to, with the plan or edition you use, since connection options can differ by plan. Say who holds the admin access for each tool.

Must-have now, and later

Split the features into the first release and the wish list. The first release should do the main job completely. Everything else can be priced separately, which keeps the first quote honest and the first launch early.

How you will judge success

Pick two or three measures from the problem paragraph: hours saved, errors avoided, calls reduced, orders placed. Agree how they will be measured before the build starts, so the review three months after launch is a fact rather than an opinion.

What does a discovery phase produce?

Discovery turns your brief into a plan a developer can build from. It is often a short, separately priced phase, and what it produces should be a document you own and could take to any developer.

A map of the process as it really runs

Interviews with the people who do the work, not only the owner, show the real steps, exceptions and workarounds. The map is often the first time a small business sees its own process on one page, and it can reveal steps that are no longer needed.

A data model in plain language

Which things the software keeps track of (customers, jobs, quotes, items, invoices), how they relate, and which system is the source of truth for each. Getting this right early is cheaper than any later fix.

An integration list with access confirmed

Every system to connect, the plan you are on, whether it has a suitable API, and confirmation that admin access works. Discovering mid-build that a vendor’s API is not available on your plan is an avoidable delay.

A first-release scope and a later list

What the first release will do, end to end, and what waits. The later list is as important as the scope, because it records ideas without letting them leak into the first build.

Risks, assumptions and an estimate

What could go wrong, what the estimate assumes (data quality, vendor cooperation, decision speed) and the price and timeline that follow. An estimate without written assumptions cannot be checked when something changes.

Should discovery be paid for separately?

A paid discovery phase gives you a scope you own before you commit to the full build, and it lets the developer price the build properly. It is worth paying for on anything larger than a simple integration, provided the output is a written document that belongs to you.

Who owns the code? Contracts, copyright and accounts

You should, and the contract has to say so in writing. Ownership is the one term a small business cannot fix after the fact, and it decides whether you can take the software to another developer later.

Why “work made for hire” wording may not be enough

The Copyright Office’s Circular 30 explains that a commissioned work counts as a work made for hire only if it falls within one of nine categories listed in the Copyright Act and both parties sign a written agreement saying so. Custom software is not named among the nine, so a contract that relies on that phrase alone can leave the copyright with the developer. Ask your lawyer to check the wording.

Get an assignment in writing

Under 17 U.S.C. 204, a transfer of copyright ownership is not valid unless it is in writing and signed by the owner of the rights being transferred. A software contract should therefore include an assignment of copyright in the work to your business, signed by the developer, alongside any “work made for hire” clause.

Third-party and open-source components

Modern applications are commonly built on open-source libraries and commercial components, each under its own license. You will not own those parts; you will use them under their licenses. Ask for a list of the components and their licenses at handover, so you know what obligations come with the code.

Hosting and accounts in your name

The cloud account, the domain, the code repository and every vendor account the software depends on should be opened in the business’s name with you as the owner, and the developer added as a user. Progression’s software page lists hosting in the client’s own cloud account as the answer to look for.

App store listings under your company

The store listing is a business asset too. With Apple, the organization’s legal name appears as the seller on the App Store, which is one more reason to enroll the business itself rather than letting a developer publish under their own account.

Documentation and a clean handover

Ask for setup instructions, an architecture overview, a list of environments and credentials (handed over securely), and the steps to deploy a change. The test is simple: could another competent developer take over within a week?

Which technology should small business software be built on?

Mainstream, well-supported technology that other developers already know. A small business’s biggest technical risk is not performance but being unable to find someone to maintain the software in five years.

Mainstream over fashionable

Widely used languages, frameworks and databases have large pools of developers, long support lives and plenty of documentation. Ask any developer why they chose a technology and whether you could hire someone else to work on it.

Web first, mobile when it earns it

A web application works on every device, needs no store review and is updated in one place. Many small business tools, especially internal ones, never need a store app. Add mobile when staff or customers need offline use, device features or a home-screen app.

Managed cloud services over servers you patch

Managed databases, hosting and file storage from a major cloud provider handle updates, backups and scaling that a small business cannot staff. They cost more per unit than a bare server and far less in attention. Keep the cloud account in the business’s name.

Cross-platform or native for mobile

Cross-platform frameworks such as React Native and Flutter build iOS and Android apps from one codebase; native development builds each separately. The live app development cost guide’s published price bands for a moderate app show why cross-platform is often the cheaper start; see cross-platform app development and native app development for when each fits.

Avoid lock-in you did not choose

Some platforms make it easy to start and hard to leave. Before you commit, check whether you can export your data in a standard format, whether the code can run elsewhere, and what happens to the software if the platform raises prices or closes.

How do you move old data into new software?

Carefully, and earlier than you think. Data migration is a common cause of delay in small business projects, because years of spreadsheets and old systems hold duplicates, gaps and inconsistent formats that nobody noticed until they had to be moved.

List every source

Spreadsheets, the old system, email folders, paper files that matter, and the accounting package. For each, note who maintains it, how many records it holds and whether it is still being updated.

Clean before you move

Merge duplicate customers, fix obvious errors, standardize formats for phone numbers, dates and addresses, and decide which version wins when two sources disagree. Cleaning in the old tools, before migration, is usually faster than cleaning in the new one.

Decide what not to bring

Closed jobs from ten years ago, customers who never bought, abandoned price lists. Archive them where they can be found and leave them out of the new system. Your accountant can tell you which financial records must be kept, and for how long.

Run a full trial migration

Move a complete copy of the data into a test version of the new software and have the people who use it check real records. Count records before and after. Fix the mapping and run it again until the counts and spot checks match.

Plan the cutover day

Pick a quiet day, freeze changes in the old system, run the final migration, check it, and switch everyone over at once. Keep the old system read-only for a while so people can look things up, then retire it.

Hosting, backups and uptime for a small business application

Where the software runs, how its data is protected and who hears when it stops are decisions to make before launch, not after the first outage. They are also running costs that belong in the budget from the start.

Where the software runs

Most small business applications run on a major cloud provider’s managed services: a hosting service for the application, a managed database and file storage. The account should be opened in the business’s name, with the developer added as a user, so you keep control if the relationship ends.

What hosting costs

The live app development cost guide puts cloud hosting at about $1,200 to $30,000 or more a year, scaling with use. A small internal tool sits at the low end; a customer app with many users, file uploads or heavy reporting moves up. Ask for an estimate at today’s volume and at two or three times it.

Backups and recovery targets

Agree two numbers in plain terms: how much recent data you could afford to lose (an hour, a day) and how long the business can manage without the software (an hour, a day, a week). Those answers set how often backups run and how recovery is designed, and they should be tested, not assumed.

Uptime and who gets the alert

Simple uptime checks and error alerts tell a named person when the software or an integration stops working. Decide who that is, what they do first and who they call, and write it into the support plan.

Separate test and live environments

A staging copy of the software lets changes be tested before they reach staff or customers. It costs a little more to host and saves the business from finding bugs in front of clients.

Security a small business app needs from day one

Security belongs in the first release. A small business holds the same kinds of customer data as a large one, with fewer people watching for problems, so the basics have to be built in rather than added later.

Start from a framework sized for small firms

NIST’s small business quick-start guide to its Cybersecurity Framework 2.0 organizes the work into six functions: Govern, Identify, Protect, Detect, Respond and Recover. The NIST Small Business Cybersecurity Corner collects plain-language guides by topic. The guide is written for small and medium-sized businesses with modest or no cybersecurity plans.

Multifactor authentication

CISA’s guidance on multifactor authentication says adding a second way to prove identity beyond a password can make you much more secure. Require it for every administrator, and offer it to customers wherever accounts hold money, orders or personal data.

Access control that matches roles

Broken access control is first in the OWASP Top 10:2025, the standard awareness list of web application risks. In a small business app it usually means one customer seeing another customer’s records, or a staff login that can do more than the role needs. Test it deliberately before launch.

Dependencies and the software supply chain

Software supply chain failures are third on the same list. Every library an app uses is code you did not write; keep them updated, remove the ones you do not need, and make sure someone is responsible for applying security updates after launch.

Backups you have tested restoring

A backup that has never been restored is a hope rather than a plan. Agree how often data is backed up, where the copies live, how long they are kept and how long a restore takes, then test a restore before launch and at least once a year.

Logging and alerts

Security logging and alerting failures are ninth on the OWASP list. Record sign-ins, permission changes and data exports, and send an alert to a named person when something unusual happens, so a problem is noticed in hours rather than months.

What testing should a small business software project include?

Automated tests written by the developer, testing by the people who will use the software, checks on the devices and browsers your users have, and a security review before launch. Progression’s software page describes automated tests on every change and code review before anything merges; ask any developer what their equivalent is.

Automated tests

Code that checks other code: that a quote totals correctly, that a customer cannot open another customer’s record, that an integration handles a missing field. They run every time something changes and catch regressions before you do.

Acceptance testing by your team

Before launch, the people who will use the software run through their real tasks with real data and sign off. Write the test scenarios from the workflow in your requirements, so acceptance means the job is done, not just that the screens load.

Devices and browsers

List the phones, tablets and browsers your staff and customers use and make sure each release is checked on them. Field apps also need testing with poor or no signal.

Security checks before launch

Check permissions deliberately, confirm multifactor sign-in for administrators, review the OWASP list above against the build, and make sure secrets such as API keys are stored outside the code. For apps holding sensitive data, an independent review is worth its cost.

Payment, privacy and accessibility rules for small business software

A handful of rules reach small business software, depending on what it handles. Software should be built inside them from the first release; none of this is legal advice.

Card payments and PCI DSS

The PCI Data Security Standard applies to anyone who stores, processes or transmits card data. Stripe’s integration security guide says a business that handles card numbers directly may have to meet more than 300 security controls, while low-risk integrations that send card details straight to the payment provider reduce those obligations. Merchants still attest to compliance each year, and payment pages must use TLS 1.2 or above.

The FTC Safeguards Rule for financial businesses

The Safeguards Rule (16 CFR 314) applies to many non-bank financial businesses; its examples include tax preparers, mortgage brokers, appraisers and car dealers that lease vehicles for more than 90 days. It requires multifactor authentication for anyone accessing customer information systems, secure development practices for in-house applications, and notice to the FTC within 30 days of discovering a breach of unencrypted data involving at least 500 consumers. Some provisions do not apply to firms with records on fewer than 5,000 consumers.

Health information and HIPAA business associates

Under 45 CFR 160.103, a business associate is a person or company that handles protected health information on behalf of a covered entity such as a medical practice. A developer or host in that position takes on duties under HIPAA. Under 45 CFR 164.502(e), the practice must obtain satisfactory assurance, documented in a written contract, that the business associate will safeguard the information before sharing it.

Children’s data and COPPA

The FTC’s COPPA rule (16 CFR 312) defines a child as someone under 13 and requires verifiable parental consent before an online service directed to children, or one with actual knowledge that it is collecting from a child under 13, collects their personal information, along with notice of what is collected and how it is used. Tutoring, camp and youth sports businesses should raise it early.

State privacy laws

State privacy laws apply above set thresholds. The California Privacy Protection Agency’s FAQ says the CCPA reaches for-profit businesses doing business in California that have gross annual revenue of $26.625 million or more (effective January 1, 2025), buy, sell or share the personal information of 100,000 or more California residents or households, or earn half or more of their revenue from selling or sharing it. Many small firms fall below these lines; check each state where you have customers.

Accessibility

The Justice Department’s web accessibility guidance says businesses open to the public must make their goods and services accessible to people with disabilities, including online, and points to the Web Content Accessibility Guidelines and the Section 508 Standards as helpful technical standards. Customer portals and apps should be designed and tested against WCAG from the start.

Electronic signatures and records

The federal E-SIGN Act, 15 U.S.C. 7001, says a signature, contract or record relating to a transaction in or affecting interstate or foreign commerce may not be denied legal effect solely because it is in electronic form. That is what lets a portal collect approvals and signed quotes; consumer disclosures carry extra conditions, so check them with counsel.

Freelancer, small software firm, agency or an in-house hire?

Each option suits a different size and kind of project, and the choice matters as much as the price. The question is who will own the software’s health after the first release.

A freelancer

A good independent developer suits a small, well-defined job: one integration, one internal tool, an update to an existing app. The risks are availability and continuity; if they move on, someone else must pick up their code, which is why documentation and accounts in your name matter even more.

Small software development companies

Small software development companies, often a handful of developers with a lead, suit projects that need design, development and testing together without the overhead of a large firm. Ask who exactly will work on your project and what happens if that person leaves. The same questions apply to small app development companies.

An agency that also does marketing

An agency with design, development and marketing under one roof suits customer-facing software that has to be launched and adopted as well as built. Progression’s software page describes one team from discovery through support, with adoption planned, including launch marketing for customer-facing products.

An in-house developer

Hiring makes sense once software is central and changes every week. It is a large fixed cost for a small firm: BLS data for 2025 put the national median annual wage of software developers at $135,980, before benefits, equipment and tools, and one developer cannot cover design, testing and security alone.

Offshore and nearshore teams

Lower hourly rates can stretch a budget, at the cost of more management, time-zone gaps and quality that varies by firm. There is also a tax angle since 2025: the IRS’s summary of the new research-cost rules says foreign research and experimental costs cannot be deducted in the year paid and are amortized over 15 years instead, which can change the after-tax comparison. Ask your accountant before deciding on price alone.

Three illustrative small business software projects

These scenarios are written for this guide to show how the routes, costs and rules above fit together. They are not client projects, and the figures are published US price bands, not quotes.

A five-person heating and cooling company connects its tools

The office books jobs in a scheduling product, technicians complete them on phones, and the bookkeeper retypes every finished job into the accounting package. Nothing about the trade is unusual enough to need custom software. The right route is to connect: an integration that turns a completed job into a draft invoice, with an alert when a job fails to sync. Published bands put an integration at about $15,000 to $50,000 over four to ten weeks, and the measure of success is the bookkeeper’s retyping time falling close to zero.

A twenty-person accounting firm adds a client portal

Clients email tax documents, staff save them by hand, and status questions arrive by phone every day in season. A focused portal with secure upload, status and messages fits the need; the live web portal guide puts a focused portal at about $50,000 to $120,000 over two to four months. Because tax preparers are named among the FTC Safeguards Rule’s examples of financial institutions, the build includes multifactor sign-in for everyone who accesses customer information, encryption and an incident plan from the first release.

A bakery with three shops considers an app

Regulars want to preorder and collect, and the owner wants a loyalty program. The first question is frequency: customers who buy weekly might keep an app, but online ordering on the website reaches everyone first. A progressive web app at about $30,000 to $90,000 avoids store review; a store app for restaurant-style ordering and loyalty sits at about $50,000 to $150,000 in published bands. Because the bakery sells physical goods, Apple’s rules route payment through Apple Pay or card entry rather than in-app purchase, so normal card fees apply.

What the three have in common

Each starts from a measured problem, tries the cheapest route that solves it, sets a success measure before building, and keeps accounts and code in the business’s name. None of them starts with a list of features.

How to choose a small business software development company

Choose on fit, ownership terms and support, not on the lowest quote. The right partner for a small business is one that will tell you what not to build and leave you able to switch developers later.

Ask what they would advise against building

A developer who answers every question with a build is selling hours. One who suggests configuring a tool you already pay for, or connecting two products instead of replacing them, is protecting your budget. Ask the question directly in the first call.

Read a real scope

A scope should list users, workflows, integrations, what is out of scope, assumptions, the release plan and how changes are priced. If a firm cannot show you one, its quote is a guess, and the gap between the guess and the real project will be billed later.

Meet the people who will do the work

Sales calls are often run by senior people who will not write your code. Ask who will design, build and test the software, and speak to the lead developer before signing. Continuity of people matters as much as the price.

Ask about life after launch

Who fixes a bug found on a Saturday, how quickly, and at what price? What happens when Apple or Google changes a requirement? A written support plan with response times, priced monthly, answers all three questions before they become urgent.

Compare like with like

Published rankings of US custom software firms sort them by size, reviews and location; for a small project, fit with your size matters more than position on a list. Searching for small software firms nearby turns up developers close to you, which can help during discovery workshops, though much of the build itself can run remotely. Put every shortlisted quote against the same written brief so the comparison is fair.

Red flags in a software proposal

Many software project problems are visible in the proposal before any code exists. These five are worth walking away from, or at least fixing in writing before you sign.

A fixed price without a written scope

A fixed price is only meaningful against a defined scope. Without one, every disagreement about what was included turns into a change request, and the fixed price becomes the starting price.

Code and hosting in the developer’s accounts

If the repository, the cloud account or the store listing belongs to the developer, you are renting your own software. Insist that every account is opened in the business’s name before work starts.

No mention of testing

A proposal that lists features but says nothing about how they will be tested, by whom and on which devices is pricing the easy part of the work and leaving the expensive part to you.

Support described only as “as needed”

Undefined support means undefined costs and undefined response times. Ask for a monthly support plan with named response times, or an hourly rate and a cap, written into the contract.

Every feature crammed into version one

A first release with everything in it launches late, costs more and teaches you nothing until it is finished. A partner who pushes back and suggests a smaller first release is usually the safer choice.

Working with a developer from week to week

A small business project goes best when the owner or the internal owner spends a little time every week rather than a lot of time at the end. These habits keep the build on track and the bill predictable.

A short weekly check-in

Thirty minutes to see what was built, answer open questions and agree the next priorities. Decisions made in the meeting should be written down by the developer and sent the same day, so nobody relies on memory.

Try every release yourself

Use each release on real work, not demo data, within a few days of receiving it. Problems found in week three cost far less to fix than the same problems found the week before launch.

Decide quickly, or name who decides

A developer waiting for an answer is either idle or guessing. If the owner cannot respond within a day or two, name someone who can, and give them the authority to decide within the agreed scope.

Handle new ideas without derailing the build

Ideas will come up mid-project. Add them to the shared list, ask for an estimate, and decide whether they replace something in the current release or wait. Saying “next release” protects the launch date.

Keep one channel for the project

One shared place for questions, decisions and files, rather than a mix of texts, calls and email threads, gives both sides a record and makes handover easier if people change.

After launch: maintenance, support and change requests

Launch is the start of the software’s working life, not the end of the project. Budget for upkeep from the first day, because platforms, browsers, libraries and your business all keep changing.

Platform and operating system updates

Phones and browsers update every year, and the stores raise their requirements with them. Google Play’s target API rules are a concrete example: an app that is not rebuilt for newer Android versions stops being offered to new users on newer devices. Native apps need a yearly review at minimum.

Security patches and dependency updates

Libraries publish security fixes on their own schedule. Someone has to watch for them, apply them, test the app and release it, and that work belongs in the support plan rather than in an emergency invoice.

Monitoring and uptime

Error reporting, uptime checks and alerts for failed integrations tell you about problems before customers do. For a small business the simplest version is an alert to a named person whenever an integration fails or the site stops responding.

Change requests and the backlog

New ideas arrive the week after launch. Keep them in one shared list, estimate them, and release them in planned batches. That keeps the software stable and the costs predictable, and it stops the most recent request from always jumping the queue.

When to rebuild rather than patch

When every change breaks something else, when the technology is no longer supported, or when the business has changed shape, a planned rebuild can cost less than years of patches. Documentation and clean ownership make that decision possible.

How do you get staff to use new software?

By involving them before it is built and retiring the old way on a set date. Adoption is where software can fail quietly: the new tool works, and people keep the spreadsheet anyway.

Involve the people who do the work early

Invite the staff who will use the software into discovery and prototype testing. They know the exceptions the owner has forgotten, and people adopt tools they helped shape.

Train on real tasks

Short sessions using the team’s own jobs, customers and orders work better than a tour of every screen. Record them, and write a one-page guide for the three or four tasks people do every day.

Retire the old workaround on a date

Announce the date the spreadsheet or the old form stops, then make it read-only. Running both in parallel for months doubles the work and lets the old habit win.

Give feedback a home

A single place to report problems and suggest changes, reviewed weekly, tells staff their input matters and feeds the backlog for the next release. Progression’s software page lists adoption, training and onboarding as part of the work, not an afterthought.

When should you revisit software you have already built?

When the business has changed shape, not on a fixed schedule. Software built for a ten-person firm can serve it well at twenty and start to strain at fifty.

Signs the software needs a second phase

New workarounds appearing around it, reports people now build by hand again, slow screens as data grows, or a new line of business it was never designed for. These are the same signs that justified the first build, appearing one level up.

More users, more data

Growth adds permission levels, audit trails and performance work. Plan them as a phase with its own scope rather than as a stream of small changes, so the architecture is adjusted once instead of patched many times.

Adding a customer-facing layer

An internal tool that works well is often the foundation for a portal or app that lets customers see the same information. Because the data and rules already exist, that second step can cost less than starting from nothing.

When to bring development in-house

When software changes every week and is central to how the business competes, a first in-house developer working with an outside team for design, testing and peak work is one way to make the step. The documentation and ownership terms from the first build make that transition possible.

AI features in small business software

AI is now a feature that small business software can include at reasonable cost, and small firms are using it. The SBA Office of Advocacy, drawing on Census Bureau survey data, reports that 7.6 percent of businesses used AI between September 2024 and August 2025, and that businesses with fewer than five employees used it at 8.2 percent.

Where AI helps a small firm

Drafting replies from your own past answers, reading invoices and forms into structured data, searching your own documents in plain language, and summarizing calls or notes. Each is a narrow job with a clear before-and-after measure, which is how AI features should be scoped.

Keep a person in the loop

Language models can be confidently wrong. Design the feature so a person reviews the output before it reaches a customer, a ledger or a contract, at least until you have measured how often it is right on your real work.

Decide what data may be sent to a model

Customer records, health details, financial data and anything covered by the rules above need a decision before they reach an AI provider. Check the provider’s business terms for data use and retention, and keep sensitive fields out of prompts unless the terms and your obligations allow it.

Costs that grow with use

Model usage is billed per request or per volume of text, so costs rise with adoption. The live app development cost guide puts an AI assistant or smart search feature at about $15,000 to $60,000 to build, before usage. Model the running cost at two or three times today’s volume.

Test on your own documents first

A demonstration on clean sample data says little about your messy real invoices. Run a pilot on a few hundred of your own documents and count the errors before deciding. Our AI automation agency page describes testing against real historical cases before launch.

Small business software programs to have in place before anything custom

Custom software works best on top of a sound base of bought tools. Plenty of apps to help small business owners exist for each job below; the skill is choosing few, setting them up properly and connecting them.

Accounting and payroll

Bookkeeping, invoicing, payroll and tax filing are regulated, detailed and updated every year. Buy them. Custom work in this area should be limited to integrations that feed them clean data.

Payments and point of sale

Card payments belong with a payment provider for the security reasons covered above. Choose one whose system connects to your accounting package and, if you have one, your online store.

Email, calendar and files

One shared workspace for email, calendars and documents, with multifactor sign-in for every account. It is also the platform most office automation will run on later, so choose it with integrations in mind.

Customer records

A CRM, even a simple one, gives every customer one record and every inquiry an owner. Many small firms start with the CRM built into another tool; our CRM development page covers when a custom CRM makes sense.

Website and booking

A fast website that answers customers’ questions, with booking or ordering where it fits. Our web design for small business page covers the site; custom software usually connects to it rather than replacing it.

Security basics

A password manager, multifactor sign-in everywhere, automatic updates and tested backups. These cost little and protect everything else, including any custom software you add later.

How owners use AI assistants to research software and developers

Some owners start with ChatGPT, Claude, Perplexity, Gemini, Copilot or Google’s AI Overviews, asking what software they need or who could build something. The answers are a starting point; the facts that matter (fees, rules, prices) should be checked at the source.

What owners ask

Typical questions look like these, and each rewards a specific, checkable answer rather than a brand name:

• What software does a ten-person landscaping company need, and what should it never build?
• Is it worth building an app for my bakery, or is a website with ordering enough?
• Who builds client portals for small accounting firms, and what do they cost?
• How much does it cost to connect an online store to accounting software?
• What should a software development contract say about who owns the code?

What the assistants can read

Google says there are no additional requirements to appear in AI Overviews or AI Mode beyond normal SEO best practices. OpenAI documents OAI-SearchBot for its search results, separately from its training crawler; Perplexity says PerplexityBot surfaces and links websites in its results; Anthropic describes Claude-SearchBot and Claude-User for search and user-requested fetches. Pages those crawlers may read can be quoted and linked.

Check what an assistant tells you

Store fees, tax rules and platform requirements change, and an assistant’s answer can lag behind. Before acting on an answer about costs or rules, open the vendor’s or agency’s own page, as this guide links throughout.

Ads beside the answers

Google’s Ads help on AI Overviews says ads are eligible to show above, below or within AI Overviews. An ad can appear next to an answer; it does not buy a place in the answer itself, so treat sponsored results as advertising.

If you launch customer software, publish its help pages

Once customers use your app or portal, they will ask assistants how to do things in it. Plain help pages on your own site, open to the crawlers above, give those assistants something accurate to quote. Our AEO for small business page covers how small firms get named in AI answers.

Measuring whether the software paid off

Measure the problem before the build and again three months after launch. The measures come straight from the business requirements document, which is why that document asks for numbers.

Hours saved

Time spent on the task before and after, from a simple log kept for two typical weeks each time. Multiply by the loaded hourly cost of the people involved for a figure the owner can weigh against the build and running costs.

Errors avoided

Wrong invoices, missed jobs, double bookings, stock mistakes. Count them for a month before and a month after. Errors can be the larger saving, because each one costs time and goodwill.

Revenue the software touches

For customer-facing software: orders placed through the app, repeat purchase rate, quotes sent and accepted, bookings made outside office hours. Tag those transactions at the source so they can be counted reliably.

Adoption

Software nobody uses saves nothing. Track active users each week and whether the old workaround has truly stopped. If staff still keep the spreadsheet, find out why before adding features.

How Progression works on small business software

Progression Agency builds custom software for businesses that have outgrown spreadsheets, off-the-shelf tools and manual workarounds, with discovery through support handled by one team. For small firms that means a narrow first release and nothing built that could be bought.

Scope in writing before anything is built

Every project starts with a written scope and estimate, so you know what is included, what is not and how changes are priced before development begins.

Standard tools where they fit

Where a product you can buy already does the job, we say so and integrate it instead. Progression connects CRMs, ERPs, accounting, ecommerce, payment and marketing platforms so data moves automatically instead of being re-keyed.

You own the code, data and cloud accounts

Code, data and cloud accounts are yours from day one, and the handover includes documentation and access so another team could continue if you ever needed one to.

Working software every two weeks

You see and try working software every two weeks, with a short written update, built on mainstream technology (TypeScript, React, Next.js, Node.js, Python, PostgreSQL, and React Native, Flutter, Swift or Kotlin for mobile) that you can hire for later.

Software terms a small business owner will hear

Developers use shorthand. These terms come up often in small business projects; here they are in plain language.

• API: the documented way one program asks another for data or tells it to act.
• Webhook: an automatic message one system sends to another when something happens, such as a paid order.
• MVP (minimum viable product): the smallest release that does the main job well enough for real users.
• Sprint: a short, fixed period of work, often two weeks, ending in something that can be tried.
• Backlog: the shared, prioritized list of everything that could be built next.
• Staging: a private copy of the software used for testing before changes reach real users.
• Production: the live software that staff or customers actually use.
• Repository: where the code and its history are stored; it should belong to your business.
• Deployment: the act of releasing a new version to staging or production.
• SSO (single sign-on): signing in to several tools with one company account.
• SLA (service level agreement): the written response and fix times in a support plan.
• Technical debt: shortcuts that save time now and cost time later, tracked so they can be repaid.

Related services

These pages cover the work around small business software:

• Software development company: custom software services
• App development agency
• Web development services
• Custom software vs off-the-shelf vs low-code
• Software development for startups
• App development cost guide
• MVP development
• Web app development
• Web portal development
• Dashboard development
• CRM development
• API development
• Inventory management software development
• Progressive web app development
• Cross-platform app development
• AI integration services
• AI automation agency
• n8n automation agency
• Software consulting services
• The software development life cycle
• Web design for small business
• Small business SEO
• Marketing agency for small business
• What is considered a small business?

Frequently asked questions