Most website projects have a dead zone. It starts the moment a business owner approves the work, and it ends whenever the designer finally resurfaces with something to look at. In between there is often nothing: no updates, no sense of what is being decided, no way to tell whether the project is moving or whether it quietly slid to the bottom of somebody’s list. The invoice cleared. Everything else is a guess.
That dead zone is where trust erodes, and it explains why so many small business owners end up resenting a website they paid real money for. They were never told what was happening, so they assumed the worst, and often they were right.
A managed website service should work differently, because it is built around an operating sequence rather than a project sprint. The first month follows the same path for a plumbing company as it does for a church or a dental practice, and every step exists to answer a question the owner would otherwise have to ask. Here is what those thirty days actually look like at NorthMac, step by step, including the parts that depend on you.
The First Few Days Are About Gathering Information
Nothing gets designed in week one. That surprises people, but the first phase of a managed website is almost entirely about collecting information and turning it into a single source of truth for the business.
When a new client starts, they get access to a workspace and an onboarding form. The form is longer than a contact form and shorter than homework, and it asks for the things that will end up hardcoded into dozens of places on the finished site: the legal business name and the public-facing one, the phone number customers should actually call, the email address, the physical address and whether it should be shown publicly, the service list, the areas served, the hours, the logo and photos, and the one action you most want a visitor to take.
It also asks a question most web projects skip entirely, which is what must not change. Sometimes a business has a page that ranks well, a phone number that appears on truck wraps and yard signs, or a form that routes to a specific inbox for a reason. Knowing that in advance prevents an expensive mistake later.
The reason for the front-loading is straightforward. Every question that goes unanswered during onboarding becomes a guess during the build, and every guess becomes a revision after the preview. Answering fifteen questions once is faster than correcting fifteen assumptions twice. This is also why the build window does not start on the day the payment clears; it starts when the required onboarding materials are complete. If something important is missing, we say so and the clock waits rather than the work starting on a foundation that has holes in it.
Business owners occasionally worry that they are being asked to do the work themselves. The distinction worth drawing is between information and execution. You know your hours, your services, and which of your photos are actually good. Nobody else does. Everything downstream of that, from layout to hosting configuration to the security stack, is ours.
Access Is the Step That Quietly Decides Your Timeline
The single most common reason a website launch slips is not design disagreement. It is access.
Somewhere in the first week we work through the accounts that control the website, and for an established business that list is usually longer than they expect: the domain registrar, wherever DNS is currently pointed, the existing hosting account, the WordPress admin, the analytics property, Google Search Console, the Google Business Profile, whatever service currently delivers form submissions, and any licenses tied to the current site. For a business that has been online for a decade, some of those logins were created by a nephew in 2014 and the email address on file no longer exists.
Sorting that out takes a few days when it goes well and a few weeks when it does not, which is why we start it early instead of discovering the problem the night before launch. The domain registrar matters most. Losing control of a domain is one of the few genuinely unrecoverable situations in this business, and verifying that you can still get into that account is worth doing today whether or not you ever hire anyone.
We also treat access as something you keep. Ownership of the domain and the business accounts stays with the business owner, and the managed site itself is operated by NorthMac as part of an active subscription. Those are two different things, and being clear about which is which up front prevents an awkward conversation years down the road.
Existing sites get one extra step here, which is mapping the current URLs to the new ones. Google’s site move documentation is unambiguous about this: if page addresses change, permanent server-side redirects need to be in place from the old URL to the new one, and skipping that step is how businesses lose rankings they spent years earning. Google also notes that 301 and other permanent redirects do not cause a loss in PageRank, so the redirect map is genuinely the difference between a clean transition and a self-inflicted traffic drop.
The Build Week Runs on Standard Patterns
Once the materials and access are in hand, the build itself is the least dramatic part of the month, and that is intentional.
Managed websites are built on standardized structures rather than reinvented from scratch each time. A typical local business site has a home page, an about page, a services overview with individual service pages where they earn their keep, some form of proof such as a gallery or reviews, a contact page, and a privacy policy. That skeleton covers the overwhelming majority of small businesses because the questions customers arrive with are remarkably consistent: what do you do, do you do it near me, are you any good at it, and how do I reach you.
Standardization is not a shortcut for our benefit. Custom-everything sites are fragile, slow to update, and expensive to maintain, and they tend to break in ways nobody can diagnose two years later when the person who built them is unreachable. A site built on predictable patterns can be updated in twenty minutes instead of two hours, and over the life of a subscription that difference compounds into hundreds of small changes that actually get made instead of postponed.
The build phase also includes the unglamorous configuration work that determines whether the site holds up: SSL, backups, security basics, caching, form delivery that reliably reaches your inbox rather than a spam folder, and the title and description tags that determine how your pages read in search results. Google’s Search Essentials covers the technical baseline here, and most of it is invisible to visitors and load-bearing for everything else.
Preview, Revisions, and a Launch That Runs on a Checklist
Somewhere in the second or third week, depending on how quickly onboarding wrapped, the preview goes out.
Feedback goes into one thread in the workspace rather than arriving by text on Tuesday, email on Wednesday, and a phone call on Friday that contradicts both. This is worth insisting on. Scattered feedback is how the wrong version of a headline ends up live, and how three of the five requested changes get made while two vanish. One thread means every request has a written record, a status, and a confirmation when it is done.
Revision requests during this stage are handled as build-stage changes and worked through in order. Straightforward edits move fast. A request that changes the shape of the project, such as adding a booking system that was never discussed, may extend the timeline, and we will say so at the time rather than absorbing it silently and missing a date.
Launch itself is a checklist. Desktop and mobile review, every form submitted and confirmed as delivered, phone and email links tapped on an actual phone, SSL verified, redirects in place for any changed URLs, search titles and descriptions set, analytics connected, backups running, security enabled, and written launch approval from the client before DNS changes.
One expectation deserves calibrating here, because it is the source of a lot of unnecessary anxiety in the days after launch. A new site does not appear in Google immediately. Google’s own guidance is that it can take a few weeks for Google to notice a new site or changes to an existing one, and for a site move it can take several weeks for the new URLs to fully replace the old ones in search results. Submitting your important pages through Search Console helps. Refreshing the results page on launch night does not.
Weeks Three and Four: The Part That Never Ends
The last stretch of the first month is when the service stops being a project and becomes an operating rhythm, and this is the part that most one-time website projects simply do not have.
Requests go into the request hub. You can submit as many as you want, and we work one at a time, in the order you set, so there is always a clear answer to what is happening right now. Most small changes are completed within 24 to 48 hours once the request is active and clear, and larger eligible requests can take up to a business week. A request that is specific moves quickest. “Change the homepage button to say Request an Estimate and point it at the contact page” is actionable on arrival. “Make the homepage better” earns one clarifying question and waits for the answer.
Routine updates are the everyday stuff of a working business: new hours, a seasonal closure, a staff change, a price adjustment, a new photo set, a service description that no longer matches what you sell, a testimonial worth featuring. Bigger efforts sit outside that baseline and get scoped separately, including full redesigns, new integrations, e-commerce and payment systems, advanced SEO campaigns, and ads management. Being direct about that boundary from day one is better for everyone than discovering it during an argument.
Behind the requests runs the maintenance work you never see. Core and plugin updates, backup verification, security monitoring, uptime checks, and a periodic look at whether anything has drifted. That work matters more than it used to. Patchstack’s State of WordPress Security in 2026 report counted 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, a 42 percent jump over the prior year, with 91 percent of them found in plugins rather than in WordPress core. The report also found that 46 percent of those vulnerabilities had no patch available at the time of disclosure, and that heavily targeted flaws were being exploited within hours of going public.
Read that last part carefully, because it reframes what maintenance actually is. Running updates when you happen to remember is not a security posture when the exposure window is measured in hours. Somebody has to be watching, and for most small businesses that somebody was never going to be the owner.
The month closes with a continuity note: what was built, what was launched, what was handled, and what is queued next. It takes two minutes to read, and it exists so you never have to wonder whether anyone is still paying attention to the thing you are paying for.
Thirty days in, a business should have a live site that loads fast on a phone, forms that reach a real inbox, accurate hours and services, backups running, updates handled, and one clear place to ask for changes. Nothing about that is exotic. It is simply what happens when the work is organized instead of improvised.
If your website has been sitting in that dead zone for a while, waiting on a designer who stopped answering or on a Saturday you never actually get, this is the alternative. You can start your managed website with NorthMac for $47, and from there it is built, hosted, updated, secured, monitored, and supported for one predictable monthly price. Your website gets handled. You get your Saturdays back.
