Hire a freelance web developer

Most of this work now lands on one stack, and for defensible reasons. TypeScript end to end, so a field renamed on the server breaks the build instead of breaking a page in front of a user. React for the interface. Next.js for routing, server rendering and the API routes that sit between the browser and the data. Node on the server. A REST API is still the usual contract between the front end and whatever holds the records, and a written contract — an OpenAPI document, or at minimum shared types — is what lets the two halves be worked on without one developer blocking the other. None of that is fashion; it is what keeps a tool changeable a year after it was delivered.

An internal tool is a genuinely different product from a public website, and hiring for it as though it were the same is the usual mistake. It has a small, known set of users who open it every day for years, and no acquisition funnel to optimise. Nobody has to be persuaded to use it; they have to be able to get through two hundred records before lunch. So the quality bar moves: keyboard navigation, tables that sort and filter the way a spreadsheet does, bulk actions, forms that validate against the same rules the server enforces, permissions that match how the organisation actually works, an audit trail of who changed what, and sensible behaviour when something fails. A tool that is pretty and slow will be abandoned for the spreadsheet it replaced.

Dashboards look like the easy half and are not. The chart library is a weekend; the hard part is everything behind it. Where the numbers come from, how they are aggregated, what a time range means when the plant runs night shifts across midnight, which timezone the server thinks it is in, how often the page refreshes without hammering the database, what the screen shows when a data feed has been down for an hour, and whether a figure someone will make a decision from is actually correct. A dashboard that is confidently wrong is worse than no dashboard, and a developer who starts by asking about the data rather than the layout understands that.

That point sharpens in an engineering business, where the data usually originates somewhere else entirely — a historian, a SCADA system, an ERP or MES, a fleet of devices in the field. The values arrive at an awkward rate, in raw units somebody has to scale, with gaps where a gateway was offline, and with timestamps from a clock that may not agree with yours. Reading them often means OPC UA, MQTT, Modbus TCP, a nightly file drop or somebody else’s API with no documentation. If your dashboard or portal has to read from a plant system, say so in the job post: it is the difference between a front-end job and a front-end job with a real integration inside it, and it changes who should be proposing.

The rest is the unglamorous part that decides whether you still have a working tool in two years. Responsive layouts, because the same screen gets opened on a phone on the shop floor, a wall-mounted display and somebody’s laptop. Authentication, single sign-on and roles. Database migrations. Environments and deployment, including on-premise when the data is not allowed to leave the site. Error reporting, backups and monitoring. And documentation good enough that a second developer can take over — which, on a freelance engagement, is a deliverable rather than a courtesy.