We build the technology behind HSJ.
HSJ Dev is the development and engineering team behind HSJ Host. We work across software development, web platforms, systems integrations, infrastructure and engineering support, building and maintaining the technology used across HSJ-managed projects.
Much of that work happens behind the scenes. That’s exactly where we belong.
Development should solve problems, not create new ones.
Good development is about more than getting something live.
A platform can look great and work perfectly on launch day, but that doesn’t necessarily mean it has been built well. We think about what comes next.
- How will it integrate with existing systems?
- How will it be maintained?
- What happens when requirements change?
- Can functionality be extended without rebuilding everything around it?
- Can another developer understand what has been created?
- What happens when a third-party platform changes its API or an integration stops behaving as expected?
These aren’t problems that should be considered after a project launches. They influence how we approach development from the beginning.
Our focus is on building technology that is reliable, understandable and maintainable. That doesn’t always mean choosing the newest framework, adding another platform or creating something custom. Sometimes the best engineering decision is knowing when not to build something.
The work continues after launch.
Our role isn’t simply to build something, hand it over and move on.
We work across the broader technical lifecycle, from understanding how a system should work through to development, integration, deployment, maintenance and ongoing technical support.
- Understand
- Develop
- Integrate
- Deploy
- Maintain
- Support
That gives our developers and engineers a much better understanding of what happens after launch and, importantly, what it takes to keep technology working in the real world.
We work behind the scenes.
A large part of our work sits underneath the experience that customers and end users actually see.
Our developers and engineers work across the technical layer of HSJ-managed projects, including websites, applications, content management systems, APIs, payment platforms, third-party integrations and supporting infrastructure.
Sometimes we’re developing a new feature or platform from the ground up. Other times we’re extending an existing system, connecting two platforms that were never designed to work together, investigating an unusual production issue or improving something that has accumulated years of technical complexity.
There is also plenty of work that nobody notices when it’s done properly.
- Deployments
- Updates
- Monitoring
- Testing
- Maintenance
- Documentation
- Performance
- Bug fixes
That’s development in the real world. The objective isn’t to make the engineering visible. It’s to make the technology dependable.
Building is only part of the job.
There’s often a distinction made between development and support. We don’t think the separation should be quite so rigid.
The decisions made during development directly affect how easily something can be supported later. Likewise, the issues encountered in production can teach developers a great deal about how systems should be designed in the first place.
Keeping those functions connected gives us valuable context. When something requires deeper investigation, the issue can move beyond general support and into engineering without starting the conversation again from scratch.
A developer can look at the application, understand how the functionality works, review integrations or infrastructure and determine what’s actually happening.
And when we build something new, we’re doing it knowing that there’s a good chance we’ll also be responsible for helping maintain it. That creates accountability beyond launch day.
We work with existing technology, not just new projects.
Not every good project starts with a blank screen.
Businesses often already have websites, applications and systems that perform important functions. Replacing everything simply because something newer exists isn’t necessarily good engineering.
We regularly work within existing environments. That can mean understanding someone else’s code, improving an established platform, replacing a problematic component, developing new functionality within existing architecture or gradually modernising a system without disrupting the business using it.
Legacy doesn’t automatically mean bad. New doesn’t automatically mean better. The important question is whether the technology remains appropriate for what the organisation needs it to do.
Where an existing system can be improved sensibly, we’d rather improve it than recommend rebuilding everything for the sake of starting again.
Technology is a tool, not the objective.
They’re tools. We work across different technologies because different projects have different requirements.
A content-heavy website has different needs from a payment integration. A booking platform has different requirements from an internal business application. Infrastructure supporting a high-traffic website presents different problems from a simple corporate site.
There isn’t one technology stack that makes sense for everything. Our job is to understand the requirement, the existing environment and the longer-term implications before deciding how something should be approached.
Sometimes that means custom development. Sometimes it’s using an established platform. Sometimes it’s connecting existing systems through an API. And sometimes the best solution is considerably simpler than the one originally proposed.
We care more about choosing an appropriate solution than being able to put another technology logo on a website.
- Silverstripe
- WordPress
- PHP
- Linux
- Cloudflare
- Stripe
- Microsoft
- cPanel
- REST APIs
Systems increasingly need to work together.
Very few digital projects operate in isolation anymore.
A website might need to communicate with a payment provider, booking platform, CRM, Microsoft environment, email service, analytics platform or an internal business system. That means integration work has become an important part of modern development.
Our engineering work includes connecting platforms through APIs, webhooks and other integration methods, handling the movement of data between systems and developing functionality around third-party platforms. These connections need to be considered carefully.
- Payments
- Booking
- CRM
- Microsoft
- Analytics
- REST APIs
- Webhooks
If a platform goes down
What happens if one platform becomes unavailable? Payments, booking, CRM and email do not wait for a convenient moment. If one of them drops, the rest of the stack still has to fail in a way you can see, explain and recover from. Timeouts, retries and fallbacks belong in the build, not in a support ticket two weeks later.
When an API changes
What happens when an API changes? Third-party platforms will move endpoints, payloads and authentication with little warning. The integration has to be able to move with them. That means versioning, logging the request path and keeping business rules out of a vendor’s undocumented behaviour.
Source of truth
Which system is the source of truth? Duplicate customer records, stock levels or bookings without a clear owner is how systems quietly disagree. We decide which platform owns each piece of data, what is copied, and what is only ever read. If two systems can both write the same field, you do not have an integration. You have an argument.
Failure and follow-up
What gets logged when something fails, and how do you troubleshoot a transaction six months later? A webhook that worked on the day is useless if nobody can reconstruct the payload, the customer and the downstream write. If you cannot explain a payment, a booking or a sync after the fact, the job is not finished.
The integration itself is only one part of the problem. Building it so it can be understood and supported later is just as important.
Development doesn’t end at the application.
The environment around an application matters too.
Development environments, staging, deployment processes, servers, DNS, caching, security controls, monitoring and backups can all affect how reliably software operates. That’s why our engineering work extends into infrastructure and DevOps.
It doesn’t mean every developer needs to become a systems administrator. It means development decisions shouldn’t be made without considering where and how the resulting application will actually operate.
Working closely with the infrastructure and hosting capability within HSJ gives our developers visibility beyond the code itself. When investigating an issue, we can look at the application and the environment supporting it rather than treating them as completely separate problems.
Collaboration matters.
Good development rarely happens in isolation.
Our team works with project managers, designers, marketers, infrastructure specialists, customer teams and third-party providers. Those people don’t necessarily speak in programming languages or technical specifications, nor should they have to.
Part of good engineering is being able to understand the business problem behind a technical request and communicate clearly about what’s possible, what isn’t and what trade-offs are involved. We’d rather ask questions early than make assumptions and discover the problem later.
We also believe documentation matters. People change. Requirements change. Platforms change. Important technical knowledge shouldn’t exist solely in someone’s memory or disappear when a project changes hands.
Clear communication and documentation make technology easier to operate, easier to improve and considerably easier to support.
Security and reliability aren’t optional extras.
Security isn’t something that can simply be added at the end of a project. Neither is reliability.
Both need to be considered throughout development, infrastructure and ongoing maintenance. That means thinking about access, permissions, dependencies, updates, environments, data handling, backups and how systems behave when something doesn’t go according to plan.
- Access
- Permissions
- Dependencies
- Updates
- Environments
- Data handling
- Backups
No technology is completely immune from problems. What matters is reducing unnecessary risk, understanding the systems we’re responsible for and having the capability to investigate and respond when something does happen.
Always improving what’s behind the screen.
Technology doesn’t stand still, and neither can the systems built around it.
We’re constantly improving how we develop, deploy, integrate and support our projects. That includes reviewing existing processes, improving documentation, reducing repetitive work through automation, strengthening development environments and exploring new technologies where they provide a genuine advantage.
We don’t adopt something simply because it’s new. And we don’t keep something simply because it’s familiar. The objective is continuous improvement without creating unnecessary complexity.
- Processes
- Documentation
- Automation
- Environments
- New technology
Introduce something new
Sometimes that means introducing something new. A library, a process or a platform earns its place when it removes a real problem: slower deploys, fragile integrations or work nobody should still be doing by hand.
Remove what isn’t needed
Sometimes it means removing something that no longer needs to be there. Old plugins, unused environments and overlapping tools add risk without adding capability. Taking them out is improvement too.
Leave a good system alone
Sometimes it means leaving a perfectly good system alone. Not everything needs to be rebuilt. If it is understood, supported and still fit for purpose, the better engineering decision is to keep it and make the next change carefully.
But everything can be made better.
Part of something bigger.
Our engineering operation sits alongside HSJ Host rather than operating as a traditional standalone development agency. There’s a practical reason for that.
A customer shouldn’t need one company to build their website, another to host it, another to maintain it and someone else to investigate a technical problem when the boundaries between those responsibilities become unclear.
HSJ Host provides the primary customer-facing relationship across websites, hosting, domains, infrastructure and ongoing support. Behind that relationship sits the development and engineering capability required to build, integrate, maintain and troubleshoot more complex technology.
Our developers may work directly with clients, designers, suppliers and external technical teams throughout a project, but customer services and broader commercial engagements are generally managed through HSJ Host.
Need hosting, a website or day-to-day support?
Visit HSJ Host →Looking for HSJ Host?
Website development, hosting, domains, VPS and customer support live there.
Our engineering team works behind many of those services. HSJ Host keeps the customer relationship in one place.