Most of what separates a real software partner from a vendor is boring and specific: who owns the copyright, what ships at handoff, who answers at 2am, how a change gets priced, and where an argument goes. Ask those five and the portfolio stops mattering. One of the answers surprises nearly every buyer, and it is a matter of federal law rather than opinion.
Who actually owns the code you paid for?
Probably not you, unless the contract says so using the right words. This is the most common and most expensive misunderstanding in software buying, and it is not a question of custom or fairness. It is statute.
The U.S. Copyright Office's Circular 30, revised August 2024, lays out the rule. Copyright belongs to whoever created the work. "Work made for hire" is the exception that flips authorship to the hiring party, and it applies in exactly two situations: when an employee creates the work within the scope of employment, or when the work is specially ordered or commissioned and satisfies four criteria at once. The four are that a written agreement exists, that it expressly says the work is a work made for hire, that all parties signed it, and that the work falls into one of nine enumerated categories.
Those nine categories are worth reading slowly: a contribution to a collective work, a part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas.
Software is not on that list. Neither is a web application, a mobile app, or an API.
The consequence is blunt. A contract that calls your custom software a "work made for hire" and stops there does not move the copyright, because commissioned software cannot qualify in the first place. Circular 30 states the failure mode in one sentence: "If a work fails to satisfy any of these requirements, it is not a work made for hire." The developer keeps the copyright. You are left with whatever implied license the rest of the agreement supports, which is usually narrower than what you believed you were buying, and which becomes very interesting the day you want to hire someone else to modify the system.
The remedy is ordinary and cheap: a written assignment of copyright, alongside the work-for-hire language rather than instead of it. Competent contracts carry both, because the belt-and-suspenders version lands correctly whether or not the work turns out to qualify.
There is a second trap behind the first. In Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989), the Supreme Court held that "employee" in the copyright sense is decided under general common law agency principles, not by the label the parties use. Most firms staff projects partly with independent contractors. If the firm never obtained assignments from its own subcontractors, it cannot convey to you what it does not hold, regardless of what your contract with the firm promises.
So the useful question is not "do we own the code." It is "show me the assignment clause, and show me that your subcontractors signed one too." A firm that answers immediately and specifically has been asked before. A firm that says "of course you own everything, it's standard" is telling you it has not read its own paperwork.
What actually ships when the project ends?
Ask what the handoff artifact is. The answer sorts firms quickly.
A weak answer is a zip file of the final source. That is a snapshot, not a system. The strong answer is the full repository including its commit history, transferred to an organization your company controls, plus everything that surrounds the code:
- Administrative ownership of every account the system depends on: cloud, database, DNS, registrar, email, payment processor, error tracking, and app store listings.
- The deployment pipeline itself, along with the ability to run it without anyone from the firm present.
- Secrets, where they live, and the procedure for rotating them once the engagement ends.
- A runbook covering how to deploy, how to roll back, and how to restore from backup, written for someone who was not in the room.
- The architectural decisions, including what was deliberately left out and why. Commit history matters more than it sounds. It is the record of how the system arrived at its current shape, and it is the difference between a successor developer reading intent and guessing at it. A firm that will not hand over history is usually protecting how the work was actually done.
The registrar and DNS deserve a special mention, because they are the quietest failure. Companies routinely discover years later that their domain sits in an agency's account, and the person who set it up has left. That is not a technical problem. It is an ownership problem wearing a technical costume, and it is the same category of issue as choosing between custom software and more SaaS tools: the question is who holds durable control of something the business depends on.
Who answers when it breaks at 2am, and how is a change priced?
These two questions look unrelated. They are the same question about incentives.
On support, ask for specifics rather than assurances. Is there an on-call rotation, or is there one person who happens to answer the phone? What is the response commitment, and is it in the contract or in a sales deck? Does support cover incidents only, or small changes too? What happens when the person who built your system goes on vacation? The answer "we're always available" is not a support model. It describes a firm that has not had to formalize one, which is fine until the night it is not.
On pricing, understand which model is in play and what it rewards. A fixed bid transfers risk to the firm, and the firm prices that risk. It also gives the firm a financial reason to interpret ambiguity narrowly, because every unbudgeted interpretation costs it margin. Time and materials transfers risk to you and removes that pressure, but it requires you to supervise scope. Neither is dishonest. Trouble comes from pretending the tension does not exist.
The practical question is what happens when something is not in the spec. Ask how a change request is priced, who decides whether a request is a change or a defect, and what the turnaround is on an estimate. Ask to see a real change order from another engagement with the client details removed. A firm with a clean, unremarkable process will produce one. A firm that improvises will describe the process instead of showing it.
Then ask where an argument goes. If you and the project lead disagree about whether something is in scope, who else is in the conversation? A named escalation path to someone with authority to make a commercial decision is a sign the firm has been through hard projects and survived them. No path means every dispute lands on the same person who created it.
Where does the Las Vegas part actually matter?
Less than the local search results imply, and more than "remote works fine" allows.
Proximity does not fix a missing copyright assignment or an undefined on-call rotation. Those are contract and operations problems, and a firm two miles away can fail at both. Weigh location after the substantive questions, not instead of them.
What a shared operating context does buy is friction reduction. Overlapping business hours mean an escalation happens the same day rather than the next one. Being able to sit with the people who actually use the software matters when the workflow is physical and the operators are not at desks, which is exactly the constraint behind work like the CICO timeclock project. Nevada is also a small enough market that reputation compounds, and a firm you can ask three other local operators about is easier to diligence than one you cannot.
Commerce Beacon is based in Las Vegas and works with companies locally and across the country, and the honest framing is that geography is a tiebreaker rather than a qualifier. That is the same lens behind our software development services and virtual IT management and consulting: decide what the business needs to own and who is accountable for it, then decide who to call.
Common questions
Is a bigger firm safer?
Not inherently. Size changes the failure mode rather than removing it. A larger firm is less likely to disappear and more likely to rotate your project among people who have never met you. A smaller firm gives you the person who built it and concentrates all the risk in that person's availability. Ask either one the same handoff and escalation questions and judge the answers, not the headcount.
What if we already have a system and no assignment?
Fix it going forward and find out where you actually stand. Ask the firm for a signed assignment now. Many will provide one without argument, because the omission was an oversight rather than a strategy, and a firm that refuses has told you something useful for free. Meanwhile, get administrative ownership of the accounts and a copy of the repository, since those are practical control even where the legal question is unsettled.