What people actually ask

We are a software studio. We build websites, online products and mobile apps for businesses. We also take on software that already exists and has become risky or difficult to run, whether that is because the people who built it have moved on or because it was put together in a hurry.

Because building software got much cheaper and quicker over the last few years, while looking after it did not. A lot of businesses now depend on software that nobody has ever properly checked. It works, so nobody worries, until the day it stops. Comparatively few companies want that job. We do, and doing it makes us better at building things that will not end up in the same state.

Small, and growing carefully. That is on purpose. It means the people you talk to are the people doing the work, and there is nobody in the middle turning your problem into a note for someone who has never spoken to you. It also means we take on fewer projects at once than a large agency would.

We work remotely with clients in different countries. What matters in practice is having enough overlapping hours for calls and a predictable weekly rhythm, and we commit to both in writing before we start. You also get a written update every week, so you are never waiting on a time difference to find out where something stands.

You do, once it is paid for, including everything produced along the way. It lives in your accounts from the first day, not ours. Hosting, your web address, app store listings and any other service are all set up in your name. Nothing about leaving us is made difficult on purpose.

A website or a focused web application is usually six to twelve weeks. A first release of an online product is three to six months. A mobile app is two to four months to the first store release. Checking existing software takes three to five days. Those are honest starting ranges. You get a real date in the written plan once we understand the job, and we would rather quote longer and be right.

About an hour a week while we are building. One call, plus answering the decisions that are genuinely yours to make. You also get a written update every week, so nothing depends on you being in a meeting. The early weeks are heavier, usually a few hours.

You get written instructions and a walkthrough with whoever will look after it. Then either your own team runs it, or we keep looking after it for a monthly fee. Both are fine, and we will tell you which one we think suits you. What we will not do is disappear on launch day and leave you with something nobody understands.

Yes, and it usually goes well. We work in small pieces specifically so that someone else can check them. We agree how we will work together at the start, and we are happy for your team to own parts of the work while we own others, as long as the line between them is written down.

That is normal and the way we work expects it. On a fixed price project a change is priced again, so you decide with a number in front of you. On ongoing work it is simply next week's plan. What we avoid is work quietly expanding while the date slips and nobody says anything.

Three ways. A fixed price project for a clearly defined piece of work. A monthly arrangement for software that is live and needs looking after. Or a dedicated team, where people work only on your product for an agreed period. Every written plan names one of the three, so there is never any confusion about what you are buying.

Because a number without a clear scope would mislead you. The same sentence describing a project can mean four weeks or four months depending on what already exists and what it has to connect to. You get a real, fixed number in writing after one conversation, rather than a range that quietly grows.

No. Fixed price projects end when the work is delivered. Monthly arrangements roll on and can be stopped with thirty days' notice. Dedicated team arrangements run for an agreed period and continue only if you want them to. We would rather you stayed because leaving would be a step backwards, not because a contract says so.

You give notice, and we spend part of that time writing a handover document for whoever comes next. What we built, what we watch, where the passwords are kept, what we would have done next, and any rough edges we know about. Everything already sits in your accounts. You are never held hostage by something only we know.

Possibly, and we will tell you on the first call rather than three weeks in. A single page or a one day fix is usually better handled by a freelancer, and we will say so. Checking existing software is deliberately a small, self contained piece of work, so it is often the right first step if you are unsure.

Only the people actually working on it. We do not pass your work to another company, an outsourced team, or a rotating group of contractors. Access is given narrowly and taken away when the work ends.

Anything you send us goes into a locked password manager, never into email, chat or a shared document. We ask for the least access that lets us do the job, and we ask you to remove it when we are finished. If we find your passwords sitting somewhere unsafe inside your own software, changing them is the first thing in the report.

No. What we find is confidential and covered by the agreement we sign before we get access to anything. If something ever appears in a public write up, your name is removed and you see it and approve it before it goes anywhere. If you say no, it does not go up.

Almost never, and we do not ask for it. A check is done by reading the software, nothing more. While building, we use made up test information. Where the work genuinely has to touch live customer information, it happens inside your own systems, not on our computers.

We use a small set of well established, widely used tools rather than a long list we have each touched once. That matters to you for one reason: when you need to hire someone else later, or hand the work to another company, there are plenty of people who can pick it up. If you have a technical person who wants the detail, we are happy to go through it on a call.

We build one app that runs on both, and use the phone's own features directly where something genuinely needs it. For most businesses that is the right trade, because it costs far less to build and much less to keep updated. If your app needs the very last drop of performance, such as a game or heavy graphics, we will tell you honestly that we are not the right studio.

For a check, usually yes. Most of what goes wrong is not specific to the tools: passwords left where they should not be, no working backup, the wrong people able to reach information, no safe way to undo a change. For ongoing building work in tools we do not use, no, and we would rather say so than learn at your expense.

We need to be able to read it, and that is all. We sign a confidentiality agreement before you give us anything. We do not need the ability to change anything, and we do not need your customers' information, to tell you what is wrong.

No, and not out of politeness. Almost everything we open looks like this, because it was built under time pressure by people trying to get something working. The mess is the job. What we care about is what it would cost you if it broke, not how it got that way.

It is common, and it is fixable. These tools are good at producing something that works and poor at the parts nobody sees: backups, keeping passwords safe, telling someone when a fault happens. Knowing which tool was used mostly tells us where to look first. It does not change the price or the approach.