HOW IT WORKS
Call, review, scope, then build.
You bring the problem. We figure out what to build. Some projects start with an outdated website. Others start with missed calls, paperwork, disconnected software, or a task nobody wants to keep doing by hand.
01
The first call
The first call is a working conversation. You describe what is getting in the way. We ask enough to know whether this looks like a website, software, a connection between tools, or a task that wastes time. A rough explanation is enough. You do not need a brief, a feature list, or a stack.
- What is not working today, in your words.
- Who feels it: customers, staff, or both.
- What sites, tools, or workarounds are already in use.
- What a useful next step would look like if the problem were gone.
- If a form is easier, use Contact and leave the project type as Not sure.
02
What gets reviewed
We look at the current site, the tools in use, and the steps people take. The review is how we tell a website problem from a software problem, and a software problem from a connection that was never built.
- The current website: what it can do, what it cannot, and what people actually use.
- The tools already paid for: what they hold, what they miss, and where someone still types the same fact twice.
- The live path: how a lead, order, listing, or document moves today.
- Access is asked for only when the review needs it. We will not promise to take over work we have not seen.
03
How scope is written
Scope is a written record of the work. It says what we will build, what we will leave alone, what you will own, and what launch includes. Price is written here. This site does not list package prices because the work is not a package.
- What ships, and what waits.
- What stays in place: existing tools, pages, or records worth keeping.
- Accounts, domain, code, and data: who holds them.
- How launch is defined, including the first fixes after go live.
04
How the work is done
One studio does the work from the first note to launch. You talk to the people building it. There is no intake team that writes a summary and disappears.
- Copy and structure come first when the public site is part of the work.
- Design and development share the same plan when the site and the working system share records.
- Connections to tools you already use are built when replacing those tools is the wrong move.
- Checks happen before go live. Launch is the switch plus the first fixes, not a vanishing act.
What we look at, and what goes live
Screens from live client sites. The captions name the process step. These are not before and after metrics.
Texas Hunting Land. Review. The live inventory we open when we look at how the site runs.. 
Hwy 84 Motors. Go live. The inventory on the live Hwy 84 Motors site..
Copy, design, build, launch, and handoff
These are the parts of the work after scope is written. Not every project needs every part in the same weight. A connection between two tools is not the same job as a new website.
- Copy
- The pages, the words, and the path from the first screen to a call or a form. You still approve the words that represent the business.
- Design
- Layout, type, and motion that hold up on a phone and a wide screen. Built for this business, not adapted from a purchased theme.
- Build
- The site or software itself. Inventory, applications, calculators, publishing, and connections sit here when they are in scope.
- Launch
- Technical checks, measurement, the switch to the live site, and the first fixes. Search setup belongs in the website when a website is part of the work.
- Handoff
- Hosting, the domain, the repository, and the records sit in accounts you control. You get a way to keep pages, listings, or media current when that is part of the work.
After launch
Launch includes the cutover and the first fixes. Ongoing changes, hosting help, or later features are scoped when you want them. There is no required retainer on this page.
- You already hold the accounts, the domain, the code, and the data.
- If something in the work we shipped needs a fix after cutover, that is part of launch.
- New pages, new tools, or later connections are written as a new scope.
What we need from you
- A plain description of what is getting in the way.
- Access to the current site or tools when the review needs it.
- Someone who can decide what ships and what waits.
What you keep
You keep the accounts, the domain, the code, and the data. Hosting and the repository sit in accounts you control.
Questions about the process
- How long does the review take?
- Long enough to see the current site, the tools, and the steps people take. We do not publish a fixed number of days because the work depends on what we are looking at.
- Do I need to know whether this is a website or software?
- No. That is the point of the review. The first call is about the problem, not the product name.
- Can you pick up an unfinished build?
- Sometimes. We need to see the current work before we can say whether it is safer to finish it or to start the missing piece cleanly.
- Is the first call a sales pitch?
- No. It is how we learn what is not working. If the work is not a fit, we will say so.