DanJMills exists because useful business software needs more than advice and more than code. It needs somebody to understand the real operation, make the difficult choices clear and remain close enough to delivery to know whether the plan will actually work.
01
The work came before the name
I started experimenting with websites and software at 13, then began commercial work at 17. At that age I was interested in what technology could do. Running a business taught me to care just as much about what the technology changed for the people paying for it.
That first chapter became Northplanet, a web and marketing agency I ran for seven years in Greater Manchester. I had to win work, explain ideas, deliver websites and smaller applications, support customers and learn what happened when a technical decision met a real deadline. There was no comfortable gap between the code and the commercial consequence.
I later spent another seven years as a hands-on Technical Director at Jarpa. The systems were larger and the operational responsibility was heavier, but the same lesson kept returning: the best technical answer only becomes useful when it fits the business, the users and the work that needs to happen every day.
02
Running a business changed how I look at software
A developer can look at a slow process and see a missing feature. A business owner may see delayed invoices, repeated admin, staff frustration or a customer who has been waiting too long. Both views matter, but they are not the same conversation.
My early agency years put me on both sides of that conversation. I had to understand why a customer cared before deciding what to build, then live with the decision after launch. That made me less interested in technology for its own sake and more interested in the movement of work: where information starts, who needs it, where it gets stuck and what a useful result looks like.
That is still the starting point I trust. Before discussing frameworks, databases or AI, I want to understand what your business is trying to achieve and why the current route is making that difficult.
03
I kept seeing a gap between advice and delivery
Many consultants are good at asking questions, mapping problems and writing recommendations. Many developers are good at turning a clear specification into working software. Trouble starts when the recommendation cannot survive the details of delivery, or the build starts before anybody has properly understood the operation.
DanJMills exists in that gap. My role is to understand an existing process or shape a new software idea, help decide what should happen next and remain capable of planning, prototyping and building the system. The advice is informed by delivery, and the delivery keeps returning to the business reason behind it.
That does not mean every conversation ends with custom software. Sometimes the right answer is a smaller improvement, a connection between existing tools, an off-the-shelf product or a clearer process. Good judgement includes knowing when not to create another application.
04
Why DanJMills is personal rather than another agency
DanJMills is my professional identity, not a second agency. It gives me a direct place to explain what I have learned, show how I think and let a business owner understand who will be involved before starting a conversation.
That first-person approach matters because software decisions often carry uncertainty. A neat service list cannot show how somebody handles a difficult trade-off, explains a risk or changes their mind when better evidence appears. Articles, project stories and honest technical notes can.
I also wanted to avoid executive theatre. My approved title is Business Software Consultant & Developer because it describes the work more clearly. I can help with the business decision and stay hands-on with the software. The title is less grand than some alternatives, which is probably a healthy sign.
05
The mission starts with understanding the real situation
Imagine a business whose customer requests arrive by email, move into a spreadsheet and then get copied into two other systems. The team knows the process is awkward, but the spreadsheet contains years of useful knowledge and nobody wants to break the operation while trying to improve it.
The tempting response is to begin listing screens for a replacement portal. I would rather follow a few requests from arrival to completion. Who makes each decision? Which information is repeated? Where does ownership become unclear? Which parts work well and should stay? The answers tell us whether the real problem is the spreadsheet, the handover, the missing integration or a rule nobody has written down.
A new software idea needs a different starting point. There may be no current process to observe, so the work begins with the business goal, intended users, proposed journey and the first useful version that can prove the idea. DanJMills has to support both situations without pretending they are the same job.
06
The best route is usually smaller than the first idea
Once the situation is clear, the next job is choosing a proportionate step. For the spreadsheet example, that might be a focused prototype, one automated handover or a small portal covering the riskiest part of the process. It does not have to be a grand replacement programme with a dramatic name and eighteen months of suspense.
A smaller first step creates evidence. The team can see whether the proposed workflow makes sense, whether the data is good enough and whether the improvement is worth extending. It also gives us a sensible stopping point if the idea does not create enough value.
This is part of the DanJMills mission too. I want software investment to feel clear enough to question. A recommendation should explain what problem it addresses, what it adds, what it leaves alone and what the business will learn before spending more.
07
Advice should survive contact with the build
Staying hands-on changes the quality of a recommendation. A process diagram may look elegant until permissions, historic data, failed integrations and unusual customer cases arrive. Delivery exposes those details quickly.
My main working stack includes Laravel and Vue, but the specific tools come after the decision. What matters is being able to turn a recommendation into data structures, screens, integrations, tests, deployment and ongoing ownership. It also means recognising when the technical cost has grown beyond the value of the original idea.
For the business using the spreadsheet, this creates continuity. The person who understood why the handover was failing is still present when the software has to handle it. There is less room for the original problem to disappear between a workshop, a specification and a development queue.
08
Sharing the reasoning is part of the mission
The articles on DanJMills are not meant to fill a publishing calendar. They are a way to make the reasoning visible before anybody needs to buy anything. I can explain why a prototype may be safer than a full build, when a spreadsheet has become an operational risk, how to take over an inherited application or where AI automation is genuinely useful.
I want that writing to be practical enough that somebody can make a better decision without contacting me. Hiding the useful part behind a sales call would make the content less useful and the eventual conversation less informed.
The writing also keeps me honest. Explaining a decision in plain English is a useful test. If the reason only sounds convincing when surrounded by technical language, I probably need to think about it again.
09
What I want DanJMills to stand for
I want DanJMills to stand for practical judgement, direct communication and software that earns its place in the business. That means understanding before recommending, explaining trade-offs without drama and staying close enough to the work to take responsibility for what happens next.
It also means accepting limits. I will not be the right person for every technology problem, and custom software will not be the right answer to every awkward process. Trust grows faster when those boundaries are clear.
The mission is simple: help businesses make clearer software decisions and turn the right ones into useful working systems. The name came later. The way of working has been building since that first commercial project at 17.
Useful questions
What the DanJMills mission means in practice
- Is the technical direction clearly linked to a business goal?
- Do the people building the system understand the commercial priority?
- Are risk, cost, security and delivery trade-offs visible early enough?
- Can the current platform support the next stage of growth?
