Older than your stack
IT consulting, software engineering and the systems work that sits underneath both of them, done by one person who will read your actual code and your actual infrastructure before offering you an opinion about either. There is no agency behind me, no account manager to be routed through, and no slide deck waiting for you at the end of it.
That person is Daniel Schmitz, German, working out of Asia, which in practice mostly means I am wide awake and caffeinated at the hours when infrastructure tends to start developing opinions of its own.
You usually turn up with either a system that works and a roadmap that doesn't, or a roadmap that works and a system that doesn't. I go and read both of them properly before saying anything, and then I tell you what I would genuinely do in your position, up to and including the reasonably frequent occasions where the honest answer is that you should leave the whole thing alone and go spend the budget on something else entirely.
Occasionally this means building the thing from nothing, and rather more often it means quietly repairing the thing that somebody else built and then moved on from. Either way I work inside your repository and alongside your own people, because handing a sealed black box over the fence and then invoicing for it has never struck me as an especially honest way to make a living. The languages I reach for without thinking are PHP, Go, JavaScript and TypeScript, with C and Swift when the work sits lower down the stack, plus a great deal of Bash and SQL and the markup that ends up on top of all of it. If your codebase turns out to be Java or Python or something else again I will find my way around it soon enough, because after this many years the syntax has rarely been the hard part.
Servers, networks, Linux, and the entire unglamorous layer that quietly decides whether anything sitting above it is still standing at three in the morning. In practice that has meant planning and running systems serving north of a hundred million views and several million people a month, and enough machines passing through my hands over the years to put the running total somewhere in the tens of thousands. Nearly all of that was done inside smaller companies with teams of ten or fewer, which is the part actually worth paying attention to, because it means the same numbers with a fraction of the people and nowhere at all to hide when something breaks. Very little surprises me at this point, and I hold strong and largely unfashionable opinions about backups.
Daniel Schmitz, one person, trading under the name bashgeek.net since 2001. I am German, I work out of Asia, and the practical upshot of that arrangement is that your overnight batch window happens to land squarely in the middle of my working afternoon. I get on a plane when the job genuinely needs somebody standing in front of the rack, which is rarer than it used to be but has not stopped happening entirely.
Along the way that has meant media companies and hosting providers, several turns as the CTO who ends up personally responsible for everything with a power cable attached to it, and co-founding a handful of SaaS and software businesses, some of which are safely behind me and some of which are still running today. The useful part of all that is not really the job titles. It is having sat on enough sides of the table to know what gets asked in the board meeting on Monday, and also which engineer is going to have to be awake on Sunday to answer it.
The person who scopes the work is the person who writes it, and also the person who picks up the phone when it falls over at an inconvenient hour.
That really is the whole pitch. There is no bench sitting around that needs keeping busy, nobody more junior to quietly hand the work to once the kickoff call is over, and no commercial reason whatsoever for me to stretch an engagement out past the point where your problem has actually been solved.
Tell me what is currently broken, or what you are about to build and would quite like a second opinion on before you commit to it. I read and answer my own email, usually within a day, and I will tell you honestly if it turns out to be something I shouldn't be taking on.
info@bashgeek.net