When you should just build it yourself
Some agencies will not say this, so we will. If any of these describe you, save your money.
- You need a landing page for something you are testing, and you will throw it away in three months if it does not work.
- You enjoy this kind of thing. Losing a weekend to it counts as a good weekend.
- Your business does not depend on the site. Nobody finds you through Google and nobody buys through it.
- You already understand DNS, Git and what a build failure looks like.
That is a real slice of the market and we will not talk you out of it. Go and build it. The rest of this guide is for the case where the site is tied to revenue.
What the two-minute demo leaves out
The video shows one step out of twenty. Type a prompt, watch a page appear, click deploy. Here is what it skips.
- Pointing your domain at it. Nameservers, DNS records and propagation delays, and a .com.my that wants your company documents before it will do anything. Get one record wrong and your website and your email go down together.
- Not breaking what already works. If you are replacing an existing site, every old address needs a permanent redirect to its new one. Miss that and years of Google results turn into 404 pages. You will not notice for six weeks. Then you will notice the enquiries dried up.
- Email that arrives. Your website and your email are different systems sharing one domain. SPF, DKIM and DMARC are three records that decide whether your quotation lands in the client's inbox or in their spam folder. Nothing in the site build tells you they exist.
- Security you cannot see. AI writes code confidently, including code with problems. An API key left in a public repository. A contact form with no rate limit that becomes a spam relay. A dependency with a known hole in it. Experienced developers ship these mistakes too. The difference is knowing what to look for afterwards.
- Who fixes it. Not if, when. A dependency updates and the build fails. The contact form quietly stops sending. Something breaks at 9pm on the Sunday before your biggest week of the year.
None of this is an argument that the AI tools are bad. It is an argument that building the site was never the hard part.
You could do your own accounts too
Most business owners could do their own bookkeeping. The software is cheap and the rules are learnable. Almost nobody does it.
Not because they cannot. An hour spent on the accounts is an hour not spent selling, and when something goes wrong with a filing they want a name on it that is not theirs.
That calculation did not change when AI got good. The question was never whether the work is too hard for you. It is whether the next ten hours are best spent here, and whether you want to own it when it breaks.
What you are actually paying for
Not the code. Code is the cheap part now, and you should be suspicious of anyone still pricing it like it is 2019. You are paying for four other things.
- Decisions. Which pages you actually need rather than the ones you think you need, and what the home page says in the first five seconds. Most do-it-yourself sites fail on structure and copy, not on looks. AI will happily build you a beautiful site that says nothing useful.
- The things that surround the site. Domain, DNS, email, redirects, analytics, backups and SSL. Each one is simple on its own. Together they are the part that goes wrong.
- Accountability. When it breaks, one message and it is handled. You do not debug it, you do not research it and you do not lose a Sunday to it.
- Someone who still knows your setup in two years, rather than a chat history you would have to reconstruct from memory.
How we work now, plainly
We use AI to build every website we take on. It makes us faster, and that shows up in your quote. Work that took weeks takes days now, and we are not charging you for typing.
The site you are reading was built that way. It is static, which means every page is a plain file with no database behind it, no plugins to update and no admin login to hack. Replacing the old surf7.net meant writing 23 redirect rules first, so that no address Google already knew about returns a 404. When a project genuinely needs a content system, because you are selling online, taking bookings or publishing weekly, we use the right tool for that instead of forcing everything into one shape.
After launch there is an ongoing fee, either a hosting subscription or a retainer depending on what the project needs. That is what pays for someone being responsible when something breaks. The domain stays registered in your name, and the site and its content belong to you. We would rather keep you because the service is worth paying for than because leaving is painful.
Where this comes from
- Site moves with URL changes, Google Search Central, on redirecting old addresses permanently when a site is replaced
- Email sender guidelines, Gmail, on the SPF, DKIM and DMARC records a sending domain needs
- Buying a domain, MYNIC, on the company documents a .com.my registration asks for
- Responsible use of code completion, GitHub, which states that generated code may not always be secure
- The OWASP Top 10, the standard list of risks a web application is checked against
