The person behind CatDog
I'm Malan.I build technology that people can actually live with.
I'm Malan van Wyk, the engineer behind CatDog.
My work sits across software development, cloud infrastructure, APIs, data, architecture and production systems.
Software Engineering · Cloud Architecture · Applications · APIs · Data · Production Systems
From the first question to what comes next
You bring me the problem.
I'll help find the path.
I've spent much of my career working on the parts of technology people normally only notice when they stop working: applications, integrations, infrastructure, deployments, data platforms, gateways and monitoring.
CatDog brings that experience together into something simpler. I help work out what needs to be built, build it properly and, if you want me to, continue looking after it.
01 / Why CatDog exists
Building it is only
part of the job.
It is easier than ever to create an impressive website, prototype an application or generate code. That is useful. But someone still needs to decide how the pieces fit together.
Where will it run? How will it deploy? Where does the data live? Who looks after the domain, the monitoring and the dependencies? What happens when it works in testing but fails in production?
Those are the questions I've spent a lot of time working with. Most business owners should not have to become software engineers, cloud engineers and system administrators to make their business work online.
“This is what I need the business to do.”
That is where I want the conversation to start. Then we can work out the technical path behind it.
02 / More than the visible website
The website is only
the part you can see.
Behind a good digital solution may be hosting, DNS, certificates, APIs, authentication, databases, storage, monitoring, analytics, deployments, backups and integrations.
You do not need to understand every piece. But whoever builds the system should.
Working across applications, infrastructure, cloud systems, APIs, data platforms and production support means I naturally think beyond “Does the page look good?”
- Will it keep working?
- Can it be maintained?
- Can it grow?
- Can we understand it when something goes wrong?
03 / How I think about engineering
Judgment before technology.
Six principles that shape the work. Open one to look closer.
Before choosing technology, understand the actual problem. A complicated solution to the wrong problem is still the wrong solution.
I like good architecture, but architecture should serve the requirement. Use the simplest solution that can do the job properly.
The job is not finished when the code works locally. Deployment, monitoring, maintenance, failure handling and support are part of the design.
When something breaks, start with evidence. Logs, metrics, traffic, data and behaviour usually tell a story.
The client should not need an engineering degree to understand what is happening. Technical decisions should be explainable in plain language.
Real systems teach you things once people begin using them. Good engineering leaves room to learn and improve.
04 / The work I enjoy
I like problems that
sit between systems.
Some of the most interesting problems are not purely frontend, backend or infrastructure problems. They happen where systems meet.
An application calls an API. The API sits behind a gateway. The gateway talks to a service that depends on data. The data needs to be correct; the infrastructure needs to stay available. When something goes wrong, all those layers matter.
I enjoy understanding the whole path, not one isolated piece. That is the mindset I bring to CatDog projects.
A simple website may only need a simple solution. A more complex problem may need applications, APIs, cloud infrastructure, storage, reporting or integrations. The important part is choosing what the problem actually requires.
05 / One connected view
Different layers.
One engineering mindset.
The most useful engineering work often happens where disciplines meet. I like understanding the complete path—from what the user sees to the infrastructure, integrations and data behind it.
Malan van Wyk
Engineer behind CATDOG™
Build · Integrate · OperateThe applications and interfaces people actually use.
- Angular
- TypeScript
- Web Applications
- Business Applications
- Android Applications
The infrastructure that keeps the system available.
- AWS
- Serverless
- Amazon EKS
- Kubernetes
- Hosting
- Infrastructure
The connections that make separate systems work together.
- APIs
- Kong Gateway
- API Gateway
- Authentication
- System Integration
Turn operational data into information people can act on.
- SQL
- PostgreSQL
- Amazon Redshift
- Amazon QuickSight
- Data Engineering
- Reporting
Understand what happens after software reaches production.
- Monitoring
- Production Support
- Troubleshooting
- Deployments
- Performance
- Reliability
Different disciplines. One connected engineering view.
06 / My relationship with technology
Tools change.
Responsibility doesn't.
I'm positive about AI and modern development tools. They help me explore ideas faster, automate repetitive work and shorten parts of the development cycle. I use tools that help me work better.
The important questions remain: what should we build, and why? How should it fit together? How do we secure and operate it? What happens when it fails? Is it actually helping the business?
Tools can accelerate the work. Engineering judgment turns the pieces into a dependable system. That is what I want CatDog to bring to a project—not simply more code, faster.
07 / A reminder, not a slogan
By Wisdom
We Build.
Building is not only about knowing how.
It is also about knowing why.
Good engineering requires judgment. When to use something—and when not to. When complexity is justified, and when the simpler option is better. When to move quickly, and when to slow down and understand the problem.
For me, “By Wisdom We Build.” means making considered decisions before writing code—and building technology that has a reason to exist.
08 / Who you'll actually work with
You'll work with
the person building it.
CatDog is intentionally owner-led. When we discuss a technical problem, you are speaking to the person closely involved in understanding it, designing the solution and making the important technical decisions.
There isn't a sales team handing your project to someone you've never met. For the right client, I think that creates a better relationship: shorter communication paths, fewer assumptions and clearer technical ownership.
Technology without theatre.
I don't want to sell complexity for its own sake, recommend a tool because it is fashionable, or leave you with a system you cannot understand, operate or justify.
The goal is not to make technology look difficult. It is to make difficult technology manageable.
09 / Let's start with the problem
You don't need
the technical answer yet.
If you know what you want to achieve—or even just what is currently frustrating you—that is enough to start.
Tell me the problem. We'll work out the technology from there.
By Wisdom We Build.