ViewBinary Digital — Singapore
How to judge a finished website or app
A build can look finished and still be fragile. This guide covers what to check when reviewing a website or app, and what to expect from support after launch. It is written for business readers, not developers, so the checks are things you can actually verify.
Start here
Start with the user's experience
Open the product on a phone, on a laptop, and on a slow connection. Most quality problems show up in the first five minutes of real use, not in a demo on a fast office network.
-
Load
Does it load in a reasonable time on a connection you would actually have in a café or on a train, not just on office wifi?
-
Touch
Do buttons respond on the first tap, without a second press or a dead zone near the edge of the screen?
-
Rotate
Does anything break when you rotate the screen, resize the window, or switch between portrait and landscape?
-
Finish
Can you complete one real task end to end — find a product, fill a form, reach a confirmation — without asking someone how?
Four checks a non-developer can run in one sitting
Speed and response
Performance
Performance is about how quickly pages load and how smoothly they respond. Check the largest pages, not just the home page. Images and scripts are common causes of slowness, and they are fixable. If a page feels sluggish on a normal connection, ask what is being loaded and why.
Watch the heavy pages
Category listings, search results, and long articles usually carry more images and scripts than the home page, so they slow down first.
Ask what loads first
The content someone came for should appear before fonts, tracking scripts, chat widgets, and marketing tags.
Check the images
Full-size photos squeezed into small frames are one of the easiest things to fix, and one of the most common causes of a slow first screen.
Judge the response, not the number
You do not need a technical score. If a tap takes a visible beat to react, that is the finding — and it belongs in the handover notes.
Responsive design
A responsive build adapts to different screen sizes. Test the key flows on a small phone, a tablet, and a desktop. Check that text is readable without zooming, that forms are usable, and that nothing overlaps. Responsive problems are usually visible immediately, which makes them easy to catch before launch.
Small phone
Check the narrowest screen your customers actually use. Text should stay readable without pinching, and tap targets should not sit on top of each other.
Tablet
Tablets often expose the gap between the phone layout and the desktop layout. Forms and navigation are where that shows up first.
Desktop
Wide screens can leave text stretched into unreadable lines or leave a lot of empty space. Both are worth noting before sign-off.
Accessibility
Accessibility means people with different abilities can use the product. These are not optional extras, and fixing them later is harder than building them in.
Keyboard
Put the mouse aside and move through the page with the tab key. You should always be able to see where you are, and reach the thing you came for.
Image descriptions
Every meaningful image should carry a short text description, so people using a screen reader get the same information you do.
Contrast
Check that text stands out clearly from its background. Pale grey on white is the most common problem, and the easiest to correct.
One product, several platforms
Cross-platform consistency
If the product runs on iOS and Android, or on web and mobile, check that the experience holds together. Features should behave the same way, even if the visual details differ. Inconsistency confuses users and usually signals that the platforms were built separately without a shared plan.
The practical test is simple: do the same three things on each platform and compare the results. If a discount appears on one and not the other, or a confirmation screen disappears, that is a planning gap rather than a design choice.
What to compare
- The same search, run on each platform
- The same checkout or enquiry flow, start to finish
- The same account sign-in and error messages
- The same notification, on both devices
Before you sign off
Testing before launch
Ask what was tested and how. A build should be checked on real devices, not just in a browser preview. Forms, payments, and login flows deserve extra attention, because they are where failures cost the most. If testing was thin, say so before launch, not after.
Real devices
Ask which phones, tablets, and browsers were used, and on which connection speed.
Forms and payments
Run one real transaction or enquiry yourself, with a real card or account, before launch day.
Sign-in and recovery
Test the reset-password and wrong-password paths, not only the happy path.
Written findings
Ask for the list of what was tested and what was found. An untested area is a known risk.
Code and documentation handover
If you own the code, you should receive it, along with basic documentation. Ask where it is hosted, how to deploy changes, and who has access. A build you cannot access is a build you do not control. This matters most if you ever change suppliers.
-
Repository
Where the source code lives, and whether your business owns that account.
-
Hosting
Which service runs the site or app, what it costs, and whose name is on the billing account.
-
Deployment
The written steps to publish a change, so a new supplier can follow them without guessing.
-
Access list
Everyone who can still reach the systems after launch, and a date to review that list.
After launch
Post-launch support
Support is where projects quietly fail. Ask what is covered, for how long, and how issues are reported. A clear support agreement beats a vague promise of help. Find out the response time for urgent problems, and whether updates cost extra.
What the agreement covers
Scope
Bugs, small content edits, and platform updates are three different jobs. Find out which of them are included, and which are quoted separately.
How long it lasts
Term
A defined period, with a clear date when it ends, is easier to plan around than an open-ended promise of help.
How issues are reported
Channel
One agreed channel — email or a shared tracker — so nothing is lost between a phone call and a chat message.
Response time for urgent problems
Priority
Ask how a problem that stops sales is treated differently from a cosmetic request, and write that difference down.
Maintenance over time
Websites and apps need updates. Dependencies age, security patches arrive, and platforms change their rules. Ask who handles this and on what schedule. A product that is not maintained becomes harder and more expensive to fix later.
Who owns the updates
A named person or team, not an email address that changes when staff move on.
On what schedule
A routine review every few months is easier to fund than an emergency repair after something breaks.
What it costs
Ask for the rate or retainer in writing, so the choice between a repair now and a rebuild later is a real comparison.
Maintenance is a budget line, not a favour
Before sign-off
Questions for a finished build
If any answer is unclear, get it in writing before you sign off. These are the questions that decide whether you control the product after launch.
-
Does it load quickly on a normal connection?
Test on mobile data, not office wifi, and note the pages that feel slow.
-
Does it work on phone, tablet, and desktop?
Walk one key flow on each size and check that nothing overlaps or disappears.
-
Can you navigate it with a keyboard?
Tab through the page and confirm you can always see where the focus is.
-
Was it tested on real devices?
Ask for the device and browser list, and for the findings, not just the outcome.
-
Do you have the code and access?
Repository, hosting account, and admin credentials in your own name or your company's.
-
Is there a written support agreement?
Scope, term, reporting channel, and response time, in a document you can keep.
Common questions about reviewing a build
Do I need a developer to run these checks? View
No. Everything on this page can be checked from a phone and a laptop. Load times, responsive behaviour, keyboard navigation, and contrast are visible to anyone who looks carefully. A developer is useful when you need to understand why something is slow or how to fix it.
What if the supplier says the code belongs to them? View
Ownership of the code and of the accounts it runs on should be settled in the original agreement. If it was never written down, raise it now, before you need to change suppliers or make a large update. Being able to leave is part of what you paid for.
How often should a website or app be maintained? View
A routine review every few months covers most businesses. The interval depends on how much the product changes, how many outside services it depends on, and whether it handles payments or personal data. The point is to have a schedule at all, rather than waiting for something to break.
Is a support agreement the same as a warranty? View
They are usually different documents. A warranty tends to cover defects in what was delivered. Support covers ongoing help, small changes, and updates after that period. Ask to see both, and check what happens when each one ends.
The checks on this page are the ones that decide whether a build still works when the original team is no longer watching.
Keep reading
Where the review fits
Evaluating a build makes most sense alongside the planning and tooling decisions that came before it. Both guides are written for the same reader.
Bring your questions to the first conversation
If a build is already live and something about it is unclear, the fastest way to get a straight answer is to ask. We can go through the handover, the support terms, or a specific page that feels slow.
ViewBinary Digital works from Oslo, with clients across Singapore. Reach us Monday to Friday, 9:00 AM to 6:00 PM, at [email protected] or +65 6208 6962. Our address is Parkveien 15, 0350 Oslo, Norway.