How soon should I expect to see a running version of my system?

Weeks rather than months. Once the build stage starts, a reachable environment with a few real screens and real data usually exists inside the first month, even while most features are missing. What matters is not how complete it is, but that it exists on hosting you can open, so that every later status report can be checked against something rather than believed.

Is it reasonable to ask for the source code and the accounts during the project?

Yes, and the right moment is the first week. Hosting, domain, repository and payment accounts should be registered in your organisation's name, with the vendor granted access to them. Asking in the middle of a project is still reasonable, and the answer tells you a great deal: a team with nothing to hide arranges the transfer within a day or two.

The team is clearly working hard, but the project feels wrong. How do I tell difficulty from failure?

Look at the reporting rather than the effort. A healthy project brings bad news early, in specific terms, with an option attached: this stage needs another week, or this feature moves to phase two. A failing one stays positive until a deadline arrives. Ask for a written status against the original scope; the gap between the two documents is your answer.

Early signs a software project is going wrong

A project is four months into a six-month schedule. There have been weekly calls, a design file containing every screen, two presentations, and a status line that has read "on track, minor delays" since week three. What there has not been is an address anyone outside the build team can open. No deadline has been missed yet, because the only real deadline is the last one. This is what a failing project usually looks like from the buyer's seat: not a collapse, but a long stretch in which nothing can be checked.

Missed dates are lagging indicators. By the time one arrives, most of the budget is spent and every remaining option is expensive. The signals worth watching appear months earlier, and nearly all are legible to a buyer with no technical background. They are not judgements about code quality but about whether the work can be inspected at all.

Nothing running is the signal that outranks the others

After the first few weeks of build, one question does more work than any other: is there an address I can open, on a machine I do not control, that shows the system with something like my data in it? A yes, even an ugly and half-finished yes, settles most doubts. A no, repeated across several weeks, outweighs every reassurance offered alongside it.

Demos are where this hides. A slide deck describing the system is not the system. A design file with clickable hotspots is not the system either; it is a drawing of one, and drawings are produced at a rate that has no relationship to build speed. A recorded video of someone's laptop sits in between — better than a deck, but it shows what the recorder chose to show, at a moment they chose. The difference is that at an address you can press a different button.

Access is the same signal from the other side. With no account, no staging environment and no read-only view, every status report is unverifiable — and unverifiable reports drift optimistic without anyone deciding to lie.

Progress described in percentages is not progress

"It's about ninety per cent done" carries no information. It cannot be checked, cannot be shown to be wrong, and can be repeated for a very long time. The version that carries information sounds different: orders can be created, edited and cancelled; the payment callback is handled; refunds have not been started. Named capabilities, each one either finished or not.

Watch how long the last ten per cent lives. A build that has been almost finished for six weeks is not almost finished. Usually the well-understood parts were built quickly, the parts nobody understood were postponed, and the postponed parts carry the risk: integrations, permissions, the behaviour of your real data, whatever the finance team does at month end.

The person you talk to is not the person building

A project manager between you and the engineers is normal at any size. A project where nobody who writes the code has been in a call with you for a month is not. Requirements degrade in transit, and the degradation stays invisible from your side until you see the result. The test is cheap: ask for the engineer doing the work to join the next review. A team that is building produces that person; a team that is behind produces reasons.

The questions about your business stopped

Early in a serious project you get asked uncomfortable things. What happens to a return after the invoice was issued? Which of these two customer records is the real one? What does the accountant do with the month-end discount? Those questions do not run out in week three, because real systems keep meeting details only you can settle. When the questions stop, the team has either stopped building against your process or started guessing at it.

Scope changes that appear to cost nothing

A change request accepted on the spot, with no discussion of what it displaces, is not generosity. Either nobody is tracking the plan closely enough to know the effect, or the effect is being absorbed quietly and will reappear later as the explanation for a delay, or as an invoice you did not expect. A team in control answers a change with a trade: this adds about a week, or it replaces that other feature, or it belongs in the second phase. That conversation is a sign of health even when the answer is inconvenient, and what a custom system costs is settled in exactly these exchanges.

Decisions also need somewhere to live. If the only record is a call and a WhatsApp thread, then in month five two parties will remember two different agreements, both sincerely. A few written lines after each decision, sent to both sides, cost minutes and remove an entire category of dispute.

Integration left to the end is the classic failure shape

"We are integrating now", arriving as an end-stage activity, is a structural warning rather than a scheduling detail. Integration is where assumptions meet other people's systems: the payment gateway, the ERP, the bank file format, the shipping API, the e-invoicing submission. It is also where the unknowns live. Credentials take weeks to be issued, the sandbox behaves differently from production, and the other side's documentation describes an endpoint that no longer works the way it is written.

A team that defers all of that has front-loaded the comfortable work and pushed the discoverable risk into the exact period when there is no budget or calendar left to absorb it. The healthier shape is the reverse: the thinnest possible path from end to end, early. One real order moving through the real payment sandbox in the first weeks, unstyled and ugly, and then breadth built on top of a route already known to work.

The question to ask is narrow. Which external system have you connected to, in which environment, and on what date did the first successful call happen? A vague answer to a narrow question is itself an answer.

Ordinary difficulty looks different from failure

Not every hard project is a failing one. Estimates move; a stage planned at two weeks takes three. A demo produces rework, which is the demo doing its job. The bug list grows during testing, which is what testing is for.

Delays are often caused by the buyer: the data was not ready, the operations manager travelled, the third party took a month to issue credentials. Screens can look unfinished for a long time while the logic underneath is sound, and sometimes that order of work is deliberate.

Ordinary difficulty	Sign of a failing project
An estimate moves and you hear about it the week it moves	The date holds firm until the week it falls due
Rework after a demo	No demo to react to
The bug list grows during testing	There is no environment to test in
Detailed questions about your process keep coming	The questions stopped weeks ago
A scope change comes back with a time or cost attached	Scope changes are accepted silently
Screens look unfinished, the logic works	Screens look finished, nothing is behind them

A healthy project delivers bad news early, in specific terms, with an option attached. A failing one reports good news until the news is catastrophic.

The difficulty is not the signal. The shape of the reporting is.

What to ask for, in escalating order

Take these in sequence. Each step is reasonable on its own, and each produces information whatever the answer.

A running environment. Ask for an address and credentials, on hosting the vendor does not solely control, within a stated number of days. Accept it unfinished. Do not accept a video in its place.
A written status against the original scope. The original list of deliverables, each marked done, in progress, or not started, with dates. Do not accept a new document describing a different project; the comparison against what was agreed is the entire point.
Access to the code and the accounts. The repository, the cloud account, the domain, the database. If these are not already in your organisation's name, ask for them now. A refusal at this step is the most serious answer in this article, and it should change what you do next.
An outside technical review. An independent engineer, engaged for a few days, given access to the repository and the environment, and asked three narrow questions: does it run, what is built, and what remains before it is usable. This costs a fraction of one month of the build and usually takes days rather than weeks.
Stopping. Stopping becomes the cheapest remaining option when months of billing have produced nothing running, when access is refused, when the review finds the completed portion cannot be built on, or when the spend still required exceeds the cost of starting again with what you now know. If you have spent 700,000 EGP of a 1,000,000 EGP budget and none of it runs, the question is not how to rescue the 700,000. It is what the remaining 300,000 buys, here or elsewhere.

What you keep when you stop is more than it feels like at the time: the requirements, the decisions, the data model, the integration knowledge, and a specification far more precise than the one you began with. The second attempt is usually faster, because the expensive learning is already paid for.

What to settle before the next project starts

Most of this is preventable at contract stage, and none of it needs technical knowledge to insist on.

Milestones tied to something running. Payment against a demonstrable state on a shared environment, not against "design phase complete". Defining even a third of the stages this way changes the incentives across the whole project.
Accounts in your name from day one. Cloud hosting, domain, repository organisation, payment gateway, third-party API keys. The vendor is granted access; you hold ownership. This single clause changes the outcome of a bad project more than any other.
Repository access from the first commit. You do not have to read the code. Commit history is the cheapest status report available, and three quiet weeks in it say something no report will.
A written decision log, and an exit clause stating plainly what is handed over on termination: code, credentials, documentation, deployment instructions.

At Softwiro a project is delivered running and connected to infrastructure we administer, and nothing is handed over as a design file or a prototype. It is a standard worth testing during selection rather than at the end. How to choose a software company covers what to ask before signing, and what happens after delivery covers the support and ownership arrangements that follow.

The question to ask this week

If you are in a project now and cannot say where the running version lives, ask that question this week rather than next month, because the answer is cheap today and expensive in three months. To scope a new system, or to have an existing project looked at by people who will tell you plainly what is there, write to us.