BUYING GUIDE / DUE DILIGENCE
ATLAS AG — Software built around your problem
Questions to ask before hiring a software developer.
A good software engagement should make the business clearer, not more dependent on a person who speaks a different technical language. Before hiring a developer or studio, ask how the first release will be defined, what you will own, how price and date are controlled, where the software will run, and what happens after launch.
What exactly will be built first?
The first release should be described in terms of users, workflows, decisions, and a usable outcome. “Build a platform” is not scope. “A dispatcher can schedule crews, a crew can see the day and submit a completion record, and a manager can review exceptions” is closer to a release boundary.
Ask what is intentionally not included. A capable developer can always suggest more features. The quality of the engagement shows up in the choices that keep the first release small enough to ship and useful enough to matter.
Who owns the result?
Ask directly whether the client owns the source code, database, customer data, deployment configuration, and accounts for third-party services. Clarify what happens if the relationship ends. Ownership should not depend on continuing to pay a vendor for access to the product the business funded.
Atlas AG treats ownership as a default: clients own their code, database, and customer data outright. Finished software is deployed to infrastructure the client owns, while Atlas AG Managed is available separately for clients who want hosting, monitoring, updates, and support handled for them.
How are price and changes handled?
Ask whether the project is fixed scope, fixed price, and fixed date, or whether the developer expects open-ended hourly billing. Hourly work can be appropriate for small marketing changes, but an operational platform needs a shared boundary before the build begins.
Atlas AG uses paid discovery for $3,500 over two weeks. The deliverable is a specification, wireframes, and a fixed quote, and the discovery fee is credited against the build. Marketing sites are a separate engagement billed at $225 per hour with a not-to-exceed cap quoted up front, plus $50 per month for hosting.
How will we use it while it is being built?
A project should not disappear into a black box for six months. Ask how often working software will be available, who will review it, how feedback becomes a decision, and what the client must provide. Atlas AG puts working software in front of the client weekly so the product is tested against the real workflow before launch.
That cadence is not a substitute for scope. It is how a clear scope stays honest. The client can catch a vocabulary problem, a missing role, or an awkward field interaction while changing it is still reasonable.
What happens after launch?
Ask who owns deployment, monitoring, updates, backups, support, and vendor accounts. Ask what is included in the handoff and whether the client can run the software without the original developer. Third-party services such as AI, SMS, email, mapping, and payments should be visible and billed directly by their vendors to the client.
Most custom builds go live in six to ten weeks once the first release is defined. Ongoing support can continue after launch, but it should be an option the client chooses rather than a condition of ownership.
A short checklist
The right developer will answer these questions without turning them into a sales performance. They will explain tradeoffs in plain language and tell you when a build is not the right answer.
- What operational problem will the first release solve?
- What is explicitly out of scope?
- What do we own at handoff?
- What are the fixed price and target date?
- Who pays for infrastructure and metered services?
- How will we review working software each week?
- What support is optional after the release?
Continue
Start a build
If you already know what you want built, describe it. If you only know what is broken, that works too.