This week's busywork, in one message

Who will really use it, not just who signs off. One sentence about the process: “the technician writes the fault on paper and at night someone types it into the system”. What hurts: time, errors, no trail. What can't be touched: the ERP, the folder, the store, the regulation.

If there's a date, say it, even if it's uncomfortable. “We need it before the close” changes the first release. “Whenever possible” does too: it means we can propose the smallest release that already gets used. Hiding the paper and the spreadsheet because they look bad in an email doesn't help. They are the example.

The message doesn't need to classify the project. We tell you whether it's web, desktop, mobile or AI. Getting the classification wrong at the start is normal. Arriving with the format already decided and the process untold is what usually wastes a month.

We reply with a specific question or a proposal for a call. Not with a capabilities deck. If the message already carries a recognizable scope, we can talk numbers. If not, a figure in the first email doesn't hold up. The first reply isn't an automatic quote.

The call, if needed, is to look at a real example: an email, a screen, a report. Without an example, the conversation stays in adjectives. With one, we can write down what's in and what's out. If you need a non-disclosure agreement before showing that example, ask in the first message and we'll handle it before the call.

Nobody gets subscribed to an email sequence. If there's no next step, we don't insist. Work starts when there's a scope both sides can repeat in the same words. How that turns into a price is on the pricing page.

A corporate site of pages and news doesn't fit: a content management system solves that. Turning a spreadsheet three people use into a program just because the spreadsheet is scary doesn't fit. Neither does a chatbot with access to all of the company's data, or a twelve-module app for a lookup that fits in a browser.

If the process is too open to estimate, we don't invent a figure. We propose a discovery phase with an end date, or we stop. Carrying on without a scope is how you build on an assumption and bill it as if it were a project.

We work in Spanish and English, including with teams outside Spain. Handover documentation is written in the language the team will maintain the tool in. The code is delivered the same way: so another team can read it without us.

We don't need to be in your office for the first release. We do need someone on your side who can show the process and correct the screen when it's wrong. Without that person, the project is built on our assumption and the station feels it on day one.

Distance doesn't change the method: a real example, a written scope, a release someone uses, and the list of what's left running so IT and security don't find out on the last Friday.