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. We also set up and run the hosting it sits on.
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 that 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.
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.
tektology since
2013
tektology stack
C# .NET JavaScript Node.js SQL Server MongoDB
tektology clouds
Azure AWS Google Cloud DigitalOcean
tektology never
C C++ Rust
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, because the second list is what keeps the cost in check. Then we build it in pieces you can look at as the work goes.
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 before it is finished and nobody is left to carry it on. We take over what is there, find out which parts work, make it safe to change and then carry on with the build.
We set the hosting up, run it and keep it patched. Usually in your own cloud account rather than ours.
Most of what we run is hosted off site now, not on a server in the building. If your company has already settled on a cloud provider, we work inside that account rather than asking anybody to move.
Domains, DNS, certificates, backups and monitoring all live in the same account, so everything the software depends on is in one place and in your name.
How managed hosting works
TEKTOLOGY
Runs it and keeps it patched
A club, a church, a youth league, a neighborhood association. A few hundred people who care about the site and nobody obvious to look after the hosting.
Volunteer groups, small nonprofits, clubs and local associations. There is no IT department, and whoever built the last version has usually moved on.
For a site this size we can run it on our own account, so there is no login for a committee to pass around and no renewal that lapses because the treasurer changed. A site like this costs very little to run.
The domain, the content and anything we write stay yours. If the group wants to move it or run it themselves, we hand over the files and the logins and answer questions for whoever takes it on.
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.
Going live is not the end of the job. We keep looking after what we build for as long as you want us to, so nobody new has to learn the system when something needs fixing.
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 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, so you can question any part of it. If the budget does not fit, we would rather cut scope now than find out halfway through.
We deliver in small pieces and each one goes somewhere you can log in and use. If we read a requirement differently than you meant it, you see it early, while it is still cheap to put right.
Once it is live we keep it running. Updates, patches, monitoring and the small changes that only surface once people are really using it.
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.
Project rescue is the same work on a system that has stalled. We read the code, find out what works, get it stable and written down, then pick development back up.
How ongoing support worksThe things people usually want to know first.
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. The code, the documentation and the accounts the software runs on are yours, not kept on a machine here that you have to ask us about.
Probably neither. Our work has run from large corporate systems down to 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. A project that needs one of those is better off with people who specialize in it. If your system needs one, we tell you in our first reply.
Then we suggest one that fits the size of the job and tell you what it will cost to run before anything is built on it.
For a company, we would rather you did. It is a cleaner arrangement to end when the accounts were never ours to begin with. A small community group is the exception. Keeping a cloud account alive is more than most committees want to take on, so we can hold that one.
Then you can. We hand over the code, the documentation and the logins, 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, then an answer on cost and timing.
Get in touch Or email sales@tektology.com directly.