What a custom build actually looks like

The five steps

1. Discovery — find out what you already have

   Varinta goes through how the work happens now, in person or on a call. Who touches what, which spreadsheet is the real one, where the numbers come from, and which report someone rebuilds by hand every month.

   That means seeing the actual files, not a description of them. Real spreadsheets are messy and the mess is the useful part — it shows where the tool has to be forgiving.

   You do: a walkthrough of your process and a look at a few real files.
   You get: a plain-language summary of your current data and where the manual hours are going. Yours to keep whether or not the work goes ahead.

2. Scoping — agree in writing on what the build covers

   The problems the build will address are written down: exactly what the tool will do, what it will not do, what it needs from you, what it costs, and the date it is finished. One page, plain English.

   The “will not do” list matters as much as the rest. It is how a two-week project stays a two-week project. If something new comes up mid-build, it goes on a list for later rather than quietly expanding the job.

   You do: read one page and say yes, no, or change this.
   You get: a fixed scope, a fixed price, and an end date before anything is built.

3. Build — the part you mostly do not have to attend

   The tool is built against copies of your real data. You are not on the hook for daily check-ins. Expect a short update partway through, with something you can look at, so course corrections happen early rather than at the end.

   Access is set up during this step, and it is the narrowest access that makes the tool work — typically one shared folder, or read-only access to email. No passwords, ever. The Security & Your Data page explains exactly how that works and how you switch it off.

   You do: approve access to one folder or inbox, and answer the occasional question.
   You get: one mid-build check-in with something real to react to.

4. Delivery — run it on your own data, in person

   The finished tool is run together on live data and the output is compared to what you already know is true. If your gut says a number looks wrong, it gets chased down right then. That is the test that matters, not a technical one.

   The output is built to outlast the project. Excel and CSV files in folders you own, refreshed on a schedule, and where you want one, a live, auto-updating dashboard on top of those same files: one source of truth, always current, at a glance. Nothing is trapped inside an app. If a tool ever stops running, every file it has produced is still sitting there and still opens.

   You do: check the output against reality.
   You get: a working tool producing files in your own storage.

5. Handoff — you own it

   You get short written instructions covering how to run it, where the output lands, what to do if it stops, and what it is doing under the hood in language you can repeat to someone else. If you want the source code, you get the source code.

Kinds of work that fit well

Getting data out of email

Invoices, order confirmations, lead forms, and web or Facebook inquiries that arrive as messages and end up retyped into a spreadsheet.

Merging systems that do not talk

Your point-of-sale, your purchasing system, and your accounting export all describe the same business in different formats. One tool reconciles them.

Multi-location consolidation

Same business, several locations, several versions of every report. A single combined view that lets you compare sites instead of stacking PDFs.

Purchasing and margin analysis

What you paid, what you charged, and how that moved — by item, vendor, and period. Useful before a vendor negotiation rather than after it.

Recurring reports built by hand

If someone spends a day each month assembling the same report, that day is the project. The hours are countable, so the value is easy to check.

Data you do not have yet

Sometimes the answer is not in your files at all — competitor pricing, local demand, market signals. That is a sourcing project rather than a build, and it is scoped the same way.

What a build does not include

• No hosted platform, dashboard subscription, or login you have to maintain. The tool runs in your environment.
• No replacement for your accounting, point-of-sale, or inventory system. Varinta works alongside what you already run.
• No open-ended engagement. Each project has a written scope and an end date. More work means a new scope, agreed the same way.
• No autonomous software that rewrites itself on your machine. Changes are reviewed by a person before they ship.

Start a conversation →