We build custom applications, look after them for as long as you need them and take over projects other developers left unfinished. Most of our work is in C#, .NET, JavaScript and Node.js, on SQL Server and MongoDB, including older systems that still do a real job.
Not every job starts from a blank page. Most of what reaches us is already running and somebody is already depending on it.
An internal application three departments open every morning. An API a customer integrates against and notices the moment it changes. A job that runs overnight and has to be finished before anyone logs in. That is the kind of code we are comfortable in, and it is a different job from writing something new on an empty screen.
The range is wider than it sounds. We have built large C# systems for corporations, with all of the process and paperwork that comes with them, and we have built small websites for small companies where the whole thing started as one person's idea. Both get the same attention. The difference is scale, not care.
We are also not particular about whose code it is. A good deal of what we maintain we did not write, and some of it we would not have written that way. That stops mattering once it is in production and people are relying on it.
Nearly every job is one of these three. They also turn into each other. A build becomes a support arrangement, and a rescue becomes a build again once the system can be changed safely.
New work, from the first conversation through to something running in production. We start by writing down what the software has to do and what it does not have to do. That second list saves more money than any other part of the process. Then we build it in pieces you can look at rather than disappearing for three months.
Software goes stale if nobody touches it. Dependencies fall out of date, certificates expire and an operating system upgrade breaks something that had worked quietly for six years. We handle that steady trickle so it never collects into an emergency, on software we built and software we did not.
Sometimes a build stops. The money runs out, the developer moves on or the priorities change, and the project is left half finished. We take over what is there, work out what actually runs, get it into a state where changing it is not frightening, then carry on from where it stalled.
No account managers and nothing that ties you in. We are not trying to become permanently necessary to you.
There is nobody in between. Whoever answers your email is the one who will be in the code that afternoon, so nothing gets softened or lost on the way through. It also means you get a straight answer when something turns out to be harder than it looked.
Everything goes into source control you have access to from the first day, and it gets documented while it is being written rather than in a rush at the end. If you want to bring the work in house or hand it to somebody else, you should be able to do that without asking us for anything.
Most of our work is not new builds. It is systems that have been running for years and simply have to keep running. That is the part of this business we actually like, which is a large part of why we are still doing it.
You always know where things stand, and you get working software to look at along the way instead of one delivery at the end.
We work out what you are actually trying to do, which is not always what the first email describes. What happens today, what goes wrong, who has to live with it and what would count as finished. If software already exists we read it and run it before we say anything about it.
Then a plan. What gets built, in what order, roughly what each part costs and which parts carry the risk. Written in plain language, because a plan you cannot read is a plan you cannot argue with. If the budget does not fit, we would rather cut scope now than find out in month four.
Work lands in small pieces and each one goes somewhere you can log in and use. Everything is in source control from the first day. You are not waiting until the end to discover we read a requirement differently than you meant it, which is the most expensive way to find that out.
Once it is live we keep it running. Updates, patches, monitoring and the small changes that only surface once people are really using it. If you would rather take it in house we hand over the code, the documentation and the accounts, then answer questions until you no longer need us.
Support is the larger half of this business, and most of it is not dramatic. It is the ordinary work of keeping a system healthy. Watching it, updating it and fixing the small things while they are still small. Some of what we look after we wrote. A good deal of it we did not.
Project rescue is the same skill in a worse moment. A build stalled, or the one person who understood it left and took the explanation with them. We read the code, find out what genuinely works, get it stable and written down, then pick development back up.
How support and rescue actually workThe things people usually want to know first, answered straight.
There is no rate card, because the jobs are not alike. A short piece of work with a clear edge to it prices differently than an open ended support arrangement. We agree how it works before anything starts, so you get a number rather than a range that quietly moves.
You do. It lives in source control you have access to from the first day, not on a machine here that you have to ask us about. The same goes for the documentation and for the accounts the software runs on.
Probably neither. We have built large C# systems for corporations and small websites for companies with a handful of staff. If a job really is wrong for us we will say so early rather than take it and struggle.
Yes, and it is common. Sometimes that means taking one piece nobody has time for. Sometimes it means covering a system the team inherited and does not want to own. We are not trying to displace anybody.
We do not work in C, C++ or Rust. There are people who are genuinely good at those and we are not going to learn one of them on your budget. If that is what your system needs, you will hear it at the first email rather than the third invoice.
Then you should be able to. That is the whole reason for the documentation and the source control access. We hand over what we have, walk your people through it and stay reachable while they settle in.
Tell us roughly what you are building or what needs looking after. We will come back with questions and a straight answer on cost and timing. If it is not something we should take on, we will say that instead.
Get in touch Or email sales@tektology.com directly.