
Website Development
- Ibrahim Fiqhan
- Website
- March 29, 2025
Table of Contents
Websites and web applications, built to load fast and be found — then handed over with everything your team needs to run them.
From a company profile site through to a full application with accounts, dashboards, and an admin backend.
What you get
- Source code in your repository, owned by you, with no licensing strings.
- A responsive build tested on phone, tablet, and desktop.
- Hosting configured — static behind a CDN, or a VPS with containers if the project needs a server — with SSL and your domain pointed correctly.
- A CMS or editing workflow your non-technical team can actually use, so routine copy changes don’t come back to a developer.
- SEO groundwork: page titles and meta descriptions, Open Graph tags for link previews, structured data, sitemap, and robots.txt.
- Analytics installed and confirmed reporting.
- Performance targets met — measured with Lighthouse and Core Web Vitals, reported before and after.
- A CI/CD pipeline so changes deploy on merge.
- Multi-language support where you need it, with proper
hreflangand per-language metadata. - A runbook and handover session, plus 30 days of post-launch defect support.
What I can build
The four areas on the poster.
Web Profile
A company profile or personal site: home, services, portfolio, news, careers, and a contact form with spam protection.
Built as a static site in Hugo where the content changes rarely. No database to query and nothing rendered on request, so pages load in well under a second, hosting costs almost nothing, and there is very little surface left to attack. This site is one of them.
Web Application
For when a project needs accounts and roles, dashboards, an admin backend, reporting, file handling, payments, or search.
I build these in Go, PHP/Laravel, or React, depending on what the project needs and what your team can maintain afterwards. Go with server-rendered templates and htmx is my preference for internal and admin-heavy work: one binary, no frontend build step, fast without a caching layer in front. I took that far enough to write an admin panel framework for it.
The Dinas Kominfo Jatim portal is the Laravel example — a full CMS, Meilisearch delivering sub-second search across public information, Redis caching, containerised deployment, and 99% uptime through high-traffic periods.
SEO Optimization
On-page first: titles and meta descriptions, Open Graph tags for link previews, structured data, sitemap, robots.txt, and internal linking that actually connects related pages.
Then the technical work Lighthouse measures — image formats and sizing, lazy loading, render-blocking resources, caching headers — reported before and after so you can see what moved rather than taking my word for it.
And the harder case: making a JavaScript application findable at all. Single-page apps hand crawlers an empty container and lose. For USIN Academy I fixed that with build-time prerendering — all 19 routes render to static HTML carrying their own metadata, then hydrate into React. No framework migration required.
Maintenance & Updates
Dependency and security updates, backups with tested restores, uptime monitoring with alerts, and small change requests on a retainer.
Sites decay for one reason. Updating them became annoying, so nobody did it, and eighteen months later the framework is three major versions behind and every upgrade path runs through a weekend. Remove the annoyance and the decay stops.
Stack
| Layer | Options |
|---|---|
| Static sites | Hugo |
| Application (Go) | Go with htmx and server-rendered templates, GORM, Gin |
| Application (PHP) | Laravel, Livewire |
| Application (JS) | React, Alpine.js, Node |
| Styling | Tailwind CSS |
| Databases | PostgreSQL, MariaDB/MySQL, Redis |
| Search | Meilisearch |
| Hosting | Cloudflare Pages, VPS with Docker, AWS, GCP |
| Web server | Caddy, Nginx |
| CI/CD | GitLab CI, GitHub Actions, Jenkins, Bitbucket Pipelines |
How it runs
1. Scoping. Pages or features, content ownership, integrations, languages, and what’s out of scope, in writing.
2. Structure first. Repository, hosting, pipeline, and information architecture before design detail.
3. Build. Delivered on a staging URL you can review as it progresses.
4. Launch. Domain cutover, SSL, redirects from old URLs so you keep existing rankings, analytics verification.
5. Handover. CMS training, runbook, support window.
Choosing the right build
I’ll recommend static unless something genuinely requires a server, because static is faster, cheaper, and safer. If your project needs accounts, live data, or user-generated content, then it needs an application, and I’ll say that plainly rather than sell you the cheaper option and rebuild it in a year.
Get in touch
Tell me what the site needs to do and who it’s for. Send a message on WhatsApp.
