Custom software and takeover
Software that exists only at your place
Not every problem is a shop. Sometimes it is an application that has run for years, that nobody wants to touch, and without which the business stops.
When you need this
An application has to stay alive
It runs, it is needed, and the developer is no longer reachable. I work in through the code, the repository and the deployment history, and make the next steps plannable again.
Two systems do not know each other
Both are good at what they were built for, and neither was built to talk to the other. Today a person sits between them with a spreadsheet.
Replace the handwork
A routine somebody does by hand every week, because no product on the market does exactly that. Software for it is not a large project.
It cannot be bought
When the requirement is your business rather than your industry, there is no standard product for it. Then it gets built.
What I build it with
PHP and Symfony. Two examples from real work, both without a client name.
The first reads product data from a supplier. The endpoint serves XML rather than SOAP, so there is no WSDL and no generated client: fetch the document, parse it, transform it, and import into Magento, which at the time meant CSV. The unglamorous part is the point. Between two systems there is rarely a beautiful API, and usually a format you have to work with.
The second is middleware between a chatbot and the checkout: thin Symfony services that each do exactly one job and keep that logic out of the shop.
I do not name either client here. That is the normal case for this kind of work, and it means these two paragraphs are description rather than proof. What carries a name is directly below.
What carries a name
Three projects I am allowed to name, described in full: what the problem was, what was built, and what I was responsible for.
How a project starts
-
Look at it
What runs today, who uses it, and what happens if it stops for a day. That decides whether it is repaired, extended or replaced.
-
Draw a boundary
A first piece that is useful on its own. Not the whole system at once.
-
Build it and hand it over
In your setup, with your conventions. What I build should be something somebody else can carry on.
-
Run it or let it go
Either is fine. What is not fine is an application that only runs while one particular person is reachable.
Frequently Asked Questions
Will you take over somebody else’s code?
Yes, and it is a large part of this work. I work in through the code, the repository and the deployment history. A rebuild is rarely the first step and almost never the cheapest.
Rebuild or carry on developing?
That is decided after I have looked at it, not before. Anyone answering that question without reading the code is selling you an opinion.
Do you only work on shop subjects?
No. The focus is e-commerce, but the earliest integration in my records is a sport ranking from 2003 that had nothing to do with trade.
What happens if you are unavailable?
That is why work gets handed over and documented. I do not build anything that only runs while I am reachable. That exact problem is why clients call me in.
One Person, From the Question to the Code
I work out what is needed, write the requirement, organise whoever else works on it, and then build it myself. Usually that is three companies, and something is lost at every handover between them. Here there is nobody between your question and the running system.
Related services
What runs at your place that nobody wants to touch?
Describe what the application does, who needs it, and what happens if it stops for a day. I will tell you whether repairing, extending or replacing is the right move.