Agile and Lean for Business Owners: How to Watch Your Software Get Built

You have probably heard a vendor say they work in an agile way, and then heard nothing further about what that means for your budget. The methodology is real and useful, but on its own it tells you nothing you can check.

What you can check is narrower: the price agreed before each stage starts, the software you can open and click at the end of each week, and whose name the accounts are in. The rest of the vocabulary matters only if it produces those.

What a vendor is actually selling when they say agile

There are two different things hiding under the same word. One is how a team organises its work: build a small piece, show it, adjust, build the next piece. That version is good for you, because decisions get corrected while they are still cheap.

The other version is agile as an answer to the question you asked about money. Requirements will change, so the scope cannot be fixed, so the work is billed by the hour and everyone sees where it lands. Plenty of honest teams work this way and some clients are fine with it. If you are an owner who needs to know what this costs before you say yes, it puts all of the uncertainty on your side of the table.

Ask whether the flexibility applies to the work or to the invoice. Scope and price agreed in writing before each stage means the plan can still change; it just cannot change quietly. We set out how the whole process fits together in our guide to custom software development, and agile sits inside that rather than replacing it.

Lean means building less, not paying less

Lean gets read as a discount. It is closer to a rule about what you allow into the build: if nobody can point to evidence that a feature is needed, it waits.

Custom software is expensive, and we will say that before anyone else does. An engineer's week costs what it costs, and a vendor who competes on being cheaper is usually competing on how junior the person writing your code is. The number you can actually reduce is how many things get built before you have proof they earn their place.

In practical terms the reporting dashboard waits until people are using the thing daily and can say which numbers they keep asking for. The second user role waits until the first one works. This is the same argument behind starting with a small version and growing it, applied to every stage rather than only the first release.

Stages as stopping points, not sprints as ritual

Sprints are an internal rhythm for the team. They matter to you only if each one produces something you can look at, and most of the time the more useful unit for a buyer is the stage.

Discovery runs one to two weeks and produces a written plan and a fixed price. If you decide at the end of it that the timing is wrong or the number is higher than the problem is worth, the plan is still yours. You paid for the thinking and you keep it, including if you take it to another studio.

Each stage after that follows the same shape, with scope and price agreed before the stage begins, so stopping is a normal thing to do rather than a dispute. That is different from a contract for the whole build signed at the start, where walking away halfway becomes a negotiation about what you owe. The full sequence from Discovery through to handover is set out in our piece on how a project runs end to end.

Weekly demos replace status reports

A written progress update is a claim about work you cannot see, and a percentage complete is easy to write and impossible to check.

You get working software every week instead, on a private preview link that exists from the first week. You open it, click through the part that was built, and say whether it matches how the work is actually done. Your operations lead will often spot the problem in thirty seconds, because they know the supervisor signs first, or that a customer can change the delivery address after the driver has left.

Catching that in week two costs a conversation, while catching it at handover costs a rebuild, which is why the demo happens weekly rather than at the end.

Fast iteration without being locked to whoever built it

Speed has a bill attached to it, and it is usually paid later by whoever inherits the code. A team can move quickly by skipping the parts that make software legible to the next person, and you will not notice until you want to change developers.

Two things keep iteration from turning into dependence. The code, the servers, the domain and every account are in your name from day one rather than transferred at the end, so there is nothing to be released to you and nothing to hold. The reasoning behind technical decisions is recorded alongside the code, so the next developer inherits the thinking rather than a directory of files and a guess about why the approval step has two stages.

Ownership promised at handover stays a promise, while ownership from the start is something you verify by logging in this afternoon.

When agile is not the answer

If an existing tool already does what you need, iterating on a custom build just extends the invoice. Invoicing, scheduling, a straightforward shop, a help desk: these are well understood problems that subscription products handle properly, and paying to rebuild one buys you a maintenance obligation.

When that is the situation, we will tell you before Discovery starts rather than after you have paid for it. The trade-offs in both directions are laid out in our comparison of custom software and off-the-shelf tools.

Custom work earns its cost when the process is specific to your business, or when the tool you already pay for has become the reason your staff do things by hand.

How to check a vendor's claims before you sign

None of this requires you to evaluate code. Four questions do most of the work, and the answers are either specific or they are not:

• Who will I be talking to each week, and are those the people writing the code?
• When do I first see something running, and where is the link?
• Whose name are the repository, the hosting and the domain in on day one?
• If I stop after the first stage, what do I take with me?

A vendor who works the way they describe will answer all four in a sentence each. If the answer is that everything gets clarified at kickoff, you have learned something about how the rest of it will go.

Tell us what the process looks like today

There is no demo to book here and no deck. If a spreadsheet is holding together something it was never meant to, or one person is the only one who understands how the requests get sorted, describe it to us on a call and you will be talking to the engineers.

If the right answer is a tool you can subscribe to, we will point you at it. If it is not, Discovery gives you a written plan and a fixed price, and both are yours to keep whether or not you continue with us.

Message us on WhatsApp at +62 851-1769-7889 or email hello@arktik.id.