Development
What web development actually is, how our stack works and why we chose it, and the engineering habits that make a LlamaMakers site fast, safe, and rankable. Written to be readable by sellers and managers, and useful to developers.
The anatomy of a website
Every website is three layers. Understanding them explains almost every decision we make:
The LlamaMakers trick: most small-business sites do not need a live backend at all. We build static sites: every page is pre-built into finished HTML before it ever reaches the server. No database to hack, nothing to crash at 2am, and pages arrive instantly because they were ready before the visitor asked. The few dynamic needs (forms, booking, analytics) are handled by small specialized services instead of a fragile custom backend.
Our stack, and why each piece
| Layer | Tool | Why this one |
|---|---|---|
| Framework | Next.js (React) + TypeScript | Component-based building (build a card once, reuse everywhere), static export for speed, TypeScript catches bugs before the browser does. |
| Styling | Tailwind CSS v4 | Consistent spacing/type scales without a 5,000-line stylesheet; unused styles stripped automatically so shipped CSS stays tiny. |
| Motion | framer-motion + curated components (shadcn, 21st.dev) | Physics-quality animation without hand-rolling it. Components are audited before install, always. |
| Forms | Formspree (or the client's existing backend) | Reliable lead capture on a static site. Test-submitted before every launch; a silent form is a fired form. |
| Hosting | Hostinger + CDN, static upload | Cheap, fast, easy handover. The out\ folder IS the deliverable; any host can serve it. |
| Foundation | The Starter Kit (F:\Burney's Websites Starter Kit) | Every project starts as a copy. SEO scaffolding (metadata, sitemap, robots, JSON-LD), animation wrappers, and config-driven site settings are prewired in lib/site-config.ts. |
Nothing religious: WordPress is fine for big editorial teams. But for a small business site it means a database, a theme, and a stack of plugins that all need updates forever, and every one of them slows the page and widens the attack surface. Our whole speed and security story comes from NOT having those moving parts. This is also the sales answer to "why custom?": fewer parts, faster site, nothing to break.
Core concepts everyone should understand
Speed (the 0.2s promise)
- Where speed comes from: pre-built pages (no server thinking time), small images (WebP, sized to their container), fonts that swap instead of blocking, and shipping as little JavaScript as possible.
- Where speed dies: huge hero images, autoplay video, plugin scripts, chat widgets loaded eagerly, and fonts set to block rendering. Every build gets a Lighthouse run to prove the target.
- Why it matters commercially: conversions drop roughly 2% per extra second of load; half of mobile users abandon after 3 seconds. Speed is sales, not vanity.
Responsive design
One site, every screen. We design mobile-first because most local-business traffic is phones. QA checks 360, 390, 768, 1280, and 1440px widths; nothing may overflow, overlap, or hide content at any of them.
Accessibility
Sites must be usable by everyone: real text contrast (4.5:1 body), keyboard-reachable controls, alt text on every image, honest heading order. Beyond ethics, Google measures this and clients get sued over it.
Forms and lead capture
The most important feature on any client site is the form. Rules: a real backend, a test submission that actually arrived, an honest success message, and a notification the client will actually see. A beautiful site with a dead form is a failed project, full stop.
Domains, DNS, SSL (the launch trio)
Domain = the address. DNS = the address book entry pointing it at our hosting. SSL = the padlock (free, automatic, mandatory). We do all three for the client; the plain-English versions live in the Glossary for when they ask.
Engineering practices (house rules)
- Start every project from a fresh Starter Kit copy. Never build inside the kit folder itself; never reuse a previous client's project as a base.
- Fill lib/site-config.ts first: it drives titles, metadata, sitemap, schema. Config before pixels.
- Audit every dependency before install (who publishes it, what it pulls in); install with scripts disabled; verify after. Zero-tolerance policy after a real data-loss incident.
- Semantic HTML always: real buttons, real headings in order, landmarks. Divs with click handlers are a code smell.
- One component per concern; if you paste the same block a third time, make it a component.
- Images: WebP, width/height set (no layout shift), lazy-load below the fold, descriptive alt.
- Test the static export locally before upload; then smoke-test the LIVE domain after DNS: forms, mobile menu, speed.
- Version everything; commit at each pipeline stage so any state can be recovered.
Questions clients actually ask developers
| Question | The honest answer |
|---|---|
| "Can I edit the site myself?" | Static sites are not WordPress dashboards. Small text/image edits are included in the Care Plan (that is its job). If a client truly needs self-serve editing, that is a scoped Premium conversation, not a surprise after launch. |
| "Do I own the website?" | Yes. The domain is theirs, and at handover they get the built site files. Hosting with us is convenience, not lock-in. This is a trust point; say it plainly. |
| "Can we add a store / booking / members later?" | Yes, the stack upgrades cleanly: e-commerce and booking are Premium-tier features, quoted per scope. Nothing about starting small blocks growing later. |
| "Why is my old site slow?" | Almost always: page builders and plugins stacked over years, oversized images, and cheap shared hosting doing server work on every visit. We remove all three causes at once. |
| "Is it secure?" | A static site has no database or login to breach; SSL is on; backups run daily on our hosting. The honest caveat: nothing on the internet is unhackable, but we remove the parts that usually get hacked. |