Web development is the work of turning a design and a set of requirements into a working website or web application. ZR Tech builds sites that are fast by construction, accessible by default and handed over with the source code, so you are never dependent on one supplier.
Overview
Development is where a design becomes something that works. It is also where most of the decisions that determine a site's long-term cost are made, quietly, by whoever writes the code. A site can look identical in two builds and differ by four seconds in load time, by an entire accessibility standard, and by whether a future developer can safely change anything.
ZR Tech builds without a framework where a framework is not needed. A brochure site running on plain PHP, hand-written CSS and vanilla JavaScript has no build step, no dependency tree to rot, and no version upgrade that breaks it in eighteen months. That is a deliberate trade: it costs a little more discipline during the build and saves a great deal of maintenance afterwards. Where an application genuinely needs a framework, one is used and the reason is written into the scope.
Performance is treated as a construction decision rather than a later optimisation. That means critical CSS inlined, fonts self-hosted and subset, images served in modern formats with explicit dimensions so nothing shifts as the page loads, and JavaScript kept small enough that a mid-range phone on a Pakistani mobile connection is not left waiting. Retrofitting these things onto a finished site costs several times what building them in does.
Accessibility follows the same logic. Semantic structure, keyboard operability, visible focus states and colour contrast that passes at AA in both light and dark themes are part of a competent build. Charging separately for them implies there is a version of the work where they are absent, and that version should not be for sale.
The last part is handover. You receive the source code, the database, the documentation and a walkthrough recording. This matters commercially rather than sentimentally: it means a competent developer anywhere can pick the project up, which removes the leverage that makes agency relationships uncomfortable and makes it more likely you stay for the right reasons.
Who this is for
This service earns its cost for the situations below. If none of them describes you, say so on the call and we will point you elsewhere.
- A business whose current site loads slowly on mobile and loses visitors before the page appears.
- Anyone whose enquiry form has silently stopped sending, which is more common than most owners realise.
- A company that needs functionality no template offers, such as a booking flow or a quoting tool.
- An organisation that must meet an accessibility standard for procurement or donor requirements.
- A business that cannot get changes made because nobody else can safely edit the existing code.
- Anyone whose site was built years ago on a platform that no longer receives security updates.
What the build covers
Hand-written front end
Semantic HTML, hand-written CSS using custom properties, and JavaScript only where it earns its weight. No framework is imposed on a site that does not need one, which keeps the page light and the code readable years later.
Performance built in
Critical CSS inlined, fonts self-hosted and subset, images in AVIF or WebP with explicit dimensions, and lazy loading below the fold. Core Web Vitals are measured on real templates during the build rather than checked at the end.
Security as standard
HTTPS, a Content-Security-Policy, protective response headers, CSRF tokens on every form, rate limiting, and server-side validation of all input. None of it is an upsell.
Accessibility to WCAG 2.2 AA
Proper landmarks and heading order, full keyboard operability, visible focus indicators, associated form labels, announced errors, and contrast verified in both themes.
Forms that actually deliver
Server-side validation, spam protection that does not punish real users, an off-site log of every submission as a delivery backup, and a redirect pattern that prevents duplicate sends on refresh.
Structured data and search readiness
A connected schema graph, correct canonical tags, clean URLs and a generated sitemap, so the site is ready for search work rather than needing retrofitting later.
Editable by your team
Where content changes regularly, an editing layer is built so your staff can update pages without a developer, with the structure constrained enough that they cannot accidentally break the layout.
Full handover
Source code, database export, documentation and a walkthrough recording, delivered as a repository you own or a complete archive with setup notes.
How it works
Every engagement runs through these stages. You approve at each one before the next begins.
-
Requirements and templates
We establish what the site must do and identify the distinct page templates behind it. This is the number that drives cost: twenty pages on three templates is a smaller build than six pages on six.
-
Structure and content model
URLs, navigation and the shape of each content type are agreed before code is written. Changing this later is the single most expensive kind of rework, so it is settled first.
-
Build the templates
Each template is built and reviewed on a staging URL you can open at any time. Performance and accessibility are measured as each one is completed, not audited at the end when fixing them is expensive.
-
Content, forms and integrations
Real content is loaded, forms are wired with validation and delivery logging, and any third-party integrations are connected with error handling for when they fail.
-
Test against a checklist
Cross-browser and cross-device testing, keyboard-only navigation of every interactive element, Core Web Vitals on mobile, structured data validation, and a link check. The checklist is shared, so you see what was tested.
-
Launch and hand over
Deployment with redirects in place where URLs changed, analytics verified, then credentials, source code, documentation and a walkthrough recording transferred to you.
Making the choice
| Approach | Best when | Trade-off | Who can maintain it |
|---|---|---|---|
| Template or page builder | Budget is tight and requirements are ordinary | Slower pages, limited control, plugin dependency that grows over time | Anyone familiar with that builder |
| WordPress with a custom theme | Content changes often and staff must publish independently | Ongoing update and plugin maintenance is unavoidable | Any WordPress developer |
| Hand-built with a light admin | Speed matters, or the workflow is specific to your business | Content editing is constrained to what was built for it | Any developer who reads the documented code |
| Web application | The site is a tool rather than a brochure | Highest cost, needs ongoing ownership after launch | A developer familiar with the stack, named in the scope |
What you get out of it
- Pages that load quickly on a mid-range phone over a Pakistani mobile connection, which is how most of your visitors arrive.
- Forms that reliably deliver, with a log so a failed email never means a lost enquiry.
- A site that meets an accessibility standard you can name in a tender or a donor report.
- Search readiness built in, so later search work starts from a sound foundation rather than a repair job.
- Code any competent developer can continue, which removes single-supplier risk.
- Lower long-term cost, because fewer dependencies means fewer forced upgrades.
Common mistakes
Choosing the build from a design mockup alone
A design says nothing about how the site will be maintained, how fast it will load or who can edit it. Those questions decide the real cost of ownership and should be settled before development starts, not discovered afterwards.
Leaving performance until the end
Retrofitting speed onto a finished site means unpicking decisions made throughout the build, and it costs several times more than doing it during construction. Measure Core Web Vitals on the first template, not on the finished site.
Adding plugins instead of writing the feature
Each plugin is a dependency that must be updated, may conflict with others, and can be abandoned by its author. Five plugins to achieve what forty lines of code would do is a maintenance bill you pay every year.
Never testing the contact form after launch
Forms fail silently and often, usually after a hosting or DNS change. Every enquiry between the failure and the discovery is lost with no trace. Test monthly, and insist on a submission log independent of email.
Redesigning without a redirect map
The traffic collapse after a rebuild is almost always dropped URLs and broken redirect chains rather than the new design. Build and test the redirect map before launch, and compare indexed pages before and after.
Accepting a build with no source handover
If you do not receive the code, you cannot change suppliers without rebuilding. Ask this question during the quote stage, because the answer after the invoice is paid is rarely the one you wanted.
What this is not
This is not a page-builder service. If your requirement is genuinely ordinary and the budget is tight, a well-configured template on WordPress is often the honest answer, and you will be told that even though it is the smaller sale.
It is not design. Development builds the decisions that design makes. Where no design exists, that work is scoped separately on the web design page, and skipping it does not save money so much as move the cost into revision rounds.
It is also not a guarantee of enquiries. A fast, accessible, well-built site removes the technical reasons people leave. If the offer is unclear or the market does not know you exist, that is positioning and visibility work, and building faster pages will not substitute for it.
Tools and platforms
What the work is actually built with. Named so you can verify it and take it elsewhere if you ever want to.
What you physically receive
- A working website or application deployed to your own hosting
- Complete source code as a repository you own, or an archive with setup notes
- A database export and a documented restore procedure
- A redirect map, where URLs changed from a previous site
- Structured data implemented and validated to zero errors
- A tested checklist covering performance, accessibility and cross-device behaviour
- Written documentation and a walkthrough recording for your team
- Thirty days of defect fixes at no charge after handover
Realistic timelines
Ranges, not promises. The figure in your scope document is the one that counts.
| Scale of work | Typical elapsed time | What decides it |
|---|---|---|
| Brochure site, five to ten pages | Two to four weeks | Whether content is supplied or written for you, and how many review rounds |
| Content-managed site with an editing layer | Three to six weeks | Number of distinct templates and the complexity of the editing rules |
| E-commerce store | Four to eight weeks | Product count, payment and delivery integrations, and tax handling |
| Custom web application | Eight weeks upward | Number of user roles, reporting depth, and whether data must be migrated |
| Rebuild of an existing site | Three to six weeks | How much content must be preserved and the size of the redirect map |
Questions about web development
It is driven by the number of distinct page templates, whether content is supplied or written for you, and whether payments or logins are involved. Two sites that look similar can differ fourfold in effort, so the figure comes in a written scope after a short call rather than from a rate card.
A brochure site is typically two to four weeks, an e-commerce build four to eight, and a custom application eight weeks upward. The most common cause of delay is not development but waiting for content and approvals from the client side.
Yes, for every build, delivered as a repository you own or a complete archive with setup notes. Withholding source code is a retention tactic rather than a technical necessity, and it makes your business dependent on one supplier staying available.
Speed is designed in rather than added later: inlined critical CSS, self-hosted subset fonts, modern image formats with explicit dimensions, and minimal JavaScript. Core Web Vitals are measured on real templates during the build on a mobile connection, not on a desktop at the end.
Yes, where that is what you need. An editing layer is built for the content that genuinely changes, constrained so staff cannot accidentally break the layout. Where content almost never changes, we say so and save you the cost of an admin nobody uses.
Yes, including payment gateway and delivery integrations used in Pakistan, plus cash-on-delivery flows where that suits your market. The scoping conversation covers returns, order status and stock, because those decide the real build size more than product count does.
Yes. Supply the design files and we build from them, flagging anything that would harm performance or accessibility before starting rather than after. If no design exists, that work is scoped separately.
Defects in delivered work are fixed at no charge for thirty days after handover. Beyond that, you can take a maintenance plan or call as needed; there is no obligation to keep paying once the site is live.
Only if URLs are dropped, content is thinned or redirects break. With a tested redirect map and preserved content depth, rankings usually hold and often improve through better speed and structure. The redirect map is built before launch, not after traffic falls.
Whichever fits. WordPress suits teams publishing frequently who need a familiar editor. A hand-built site suits cases where speed, a specific workflow or an unusual integration matters more than editing convenience. The recommendation comes from your situation, not from a preference.
Last updated