Choosing a software development company in Vermont: questions to ask before you sign

Vermont has a small software community. If you are looking for a software development company in Vermont, you will probably compare a handful of local studios and freelancers with remote agencies from Boston, New York or further away.

This is a buyer's guide, not a sales page. We are one of the Vermont options, so read it with that in mind. The questions below are the ones we would ask if we were hiring a developer ourselves, and one section covers when an out-of-state firm is the better choice.

Questions about ownership

These matter more than price, because getting them wrong is expensive to undo.

Who owns the code?

You should own it outright, with no license back to the developer that limits what you can do. First, ask to see the clause in the contract. Then ask where the code will live. The best answer is a repository in an account you control, such as your own GitHub organization, with the developer added as a collaborator.

Who owns the accounts?

Hosting, domain names, app store listings, email services and payment accounts should be in your name and paid with your card. A developer can manage them for you without owning them. So if they leave, you keep everything.

What happens if the developer disappears?

People retire, get sick or take a full-time job. So ask what another engineer would need to pick up the work. A good answer includes a written overview of how the system fits together, a short runbook for deploys and backups, and code another developer can read without calling anyone.

Questions about hosting and running costs

Ask where the software will run and who pays for it. Managed hosting is usually billed monthly, directly to you, and grows with use. Then ask for a rough monthly figure at launch and at twice your current size.

Also ask about backups. How often are they taken, where are they stored, and when was a restore last tested?

Questions about how the work runs

Five questions cover the working relationship, from the first workshop to support after launch.

How do you find out what we actually need?

Good developers spend time with the people who will use the software, not just the person signing the check. Ask how they map your current process, including the exceptions.

How often will we see working software?

Monthly status reports are not enough. Instead, you should be able to click through real, working screens every week or two on a preview link. That is how problems surface early, while they are cheap to fix.

How are change requests priced?

Every project changes. Ask what happens when you want something new halfway through. Common answers are a written change order with its own price, or a time-and-materials rate for anything outside the original scope. Either is fine if it is clear before you start.

What does support cost after launch?

Software needs care after it goes live: security updates, library upgrades and small fixes. Find out whether support is a monthly retainer, an hourly rate or included for a set period, and how quickly someone responds when something breaks.

Can we talk to past clients?

Ask for one or two references for work like yours, and call them. Ask what went wrong and how the developer handled it. Every project has a bad week; you want to know what happens then.

Local or remote: does in person matter?

Most software work happens over email, calls and shared links, wherever the developer lives. In-person time matters most at three moments: the first conversation about how your business really works, the design review, and launch day.

Meeting in your shop, office or inn often surfaces details nobody would mention on a call. You see the paper form taped to the wall, or the second monitor someone uses to copy numbers between programs.

A Vermont developer also knows the context: seasonal businesses, rural internet, the rooms and meals tax, and the fact that your customers may be a two-hour drive away.

When a larger out-of-state firm is the better choice

A small studio is not right for every project. Look further afield if:

• You need a large team working in parallel on a tight deadline, with many engineers at once.
• You need round-the-clock support with a guaranteed response in minutes at any hour.
• A contract requires formal certifications, such as a completed SOC 2 audit for the vendor itself.
• You need deep experience in one niche system, such as a particular hospital records platform, that no local developer has.

If none of these apply, a smaller team often moves faster, costs less to run and keeps the same people on your project from start to finish.

About us, briefly

802 Software, LLC is a Vermont company, and the founder who leads every project lives and works here. The name comes from the state's area code. Vermont work in our portfolio includes BTV Transit, a trip planner for every Vermont public bus timetable, and Live Local Vermont, a Realtor's site with live MLS search. We meet in person anywhere in Vermont and across New England, and we also work with clients across the US.

Our answers to the ownership questions above: the repository, hosting accounts and domain are in your name from the first day, and handover documentation is part of the work. More on the Vermont page.

For a sense of what sets the price with any Vermont developer, read how much custom business software costs.

Talk it through

If you are comparing software development companies in Vermont, we are happy to be one of the calls, even if you end up hiring someone else. Send a few lines about the project and we reply within one business day.

Cover photo by Mina Rad on Unsplash.