You signed the contract on a Thursday. The following Monday a "kickoff" invite lands for 10 a.m., with seven people from the vendor you've never met and a question in the email that nobody on your team can answer: who is going to approve the user stories? That's when it hits you. You bought a project, but you're not quite sure what your side of the work looks like for the next four months.
Working with a software development company is not like buying a product and waiting for delivery. It's closer to building a house where the owner visits the site every week: there are standing meetings, things to review and decisions only you can make. If you know ahead of time what a normal week looks like, the project moves faster and the invoice holds fewer surprises.
This article walks through that week-to-week rhythm from the client's side. It doesn't cover how to pick a vendor (see 10 questions to ask before signing) or the technical detail of each phase, which we cover in software design and development stages and deliverables.
Week one: the kickoff and what to put in writing
The kickoff is the opening meeting. It usually runs one to two hours, and the goal is simple: both teams leave knowing the same things. What gets built first, who decides what, and how everyone will communicate.
By the end of that first week you should have:
- One named person at your company who owns the product. In Scrum this role is the Product Owner, and the Scrum Guide is blunt about it: the Product Owner is one person, not a committee. If three managers can each change priorities on their own, the development team will get contradictory instructions.
- A calendar of recurring meetings, with day and time.
- The official communication channel (Teams, Slack, email) and which kind of topic goes where.
- The access the vendor needs: environments, ERP APIs, test users, VPN. This item delays project starts more often than any technical problem.
- A first version of the backlog, meaning the prioritized list of features.
If the system will handle personal data about customers or employees, this is also the week to review the data processing agreement. Article 15 bis of Chile's Law 21,719 requires that contract to set out the purpose, duration, type of data and categories of data subjects.
What a normal project week looks like
After kickoff, the project settles into short cycles. The Scrum Guide caps sprints at one month or less; plenty of teams run two-week sprints, which is the rhythm used in this example.
| When | What happens | What's expected from you |
|---|---|---|
| Sprint start (Monday) | Planning: the team pulls stories from the backlog | Confirm priorities and clear up business questions |
| During the sprint | Development, quick questions through the agreed channel | Answer within 24 to 48 hours |
| Mid-sprint | Short progress check (optional, 30 min) | Flag anything that changed in the business |
| Sprint end (Friday of week two) | Demo of finished work in the test environment | Try it, comment, accept or reject |
| Between sprints | Backlog refinement | Detail the next stories with acceptance criteria |
In practice, the client-side commitment is a few hours a week for the Product Owner, plus more during testing weeks. The most common bottleneck isn't on the vendor's side. It's the question that sits unanswered for three days because the one person who knows the business rule was out in the field.
The demo every two weeks
The demo at the end of each sprint is the most important meeting for you. The Scrum Guide calls it the Sprint Review and describes it as a working session where the team and stakeholders look at what was done and decide what comes next. It adds a warning worth taking seriously: it shouldn't be reduced to a presentation. For a one-month sprint it's capped at four hours; with two-week sprints, an hour or two is usually enough.
Ask to see the system running in the test environment, the same one you'll use afterwards, not in slides. Bring one or two real users along with the managers: a warehouse operator will spot in five minutes things nobody notices in a meeting room. And before you wrap up, write down the decisions: what's approved, what needs fixing and what moves up or down the list.
If you've sat through two or three demos where everything "looks fine" but nobody has actually used it, stop and ask why.
Test environments and signing off on deliverables
A well-run project has at least three environments: development, where the team works; test (sometimes called QA or staging), where you validate; and production, where the business runs. Your team should only need access to the second one.
Approving a deliverable means checking it against criteria agreed before it was built. If the story said "given a customer with overdue debt, when an order is entered, then the system blocks it," the test is to do exactly that. If something comes up that wasn't in the criteria, that's a change, and it gets handled like one: it goes into the backlog and gets prioritized.
Two practical tips:
- Put approvals in writing, even if it's just a comment in the project tool or a short note. Six months later nobody remembers what was accepted at the sprint 4 demo.
- Don't load copies of the production database with real data into the test environment. If you need realistic data, anonymize it; we explain how in real data in test environments and Law 21,719.
About that law: its effective date is currently set for December 1, 2026. A bill would push it to October 15, 2027. The Senate has already passed it, and on November 5 the Constitution Committee of the Chamber of Deputies approved it in general and sent it on to the Finance Committee. Until it's published, the current date stands. Either way, a system built now will run for years under the law.
Communication and scope changes
Changes will come. The market shifts, leadership sees the first demo and has a better idea, an exception turns up that nobody mentioned. That's normal. Trouble starts when changes come in through the hallway, in a conversation nobody wrote down.
A setup that works:
- Every new request goes through the Product Owner, who adds it to the backlog.
- The vendor estimates its impact on time and cost before committing to it.
- If the budget is fixed, you decide what comes out so the new item can go in.
Also ask for a short status report every two weeks: what was finished, what's next, open risks and hours used against budget. Without that report, you'll probably hear about problems only once they're expensive.
If instead of a defined-scope project you're thinking about adding developers to your own team, the dynamic is different; we compare both in staff or project.
What the software company will ask of you
Almost any serious vendor will ask you for the following during the project. Having it sorted before you start saves weeks:
- Someone with the time and authority to make product decisions.
- Technical access to the systems that need integrating, with someone from your IT team who responds.
- Users available to test during demo weeks and the final acceptance test.
- Documented business rules, or at least someone who knows them and can explain them.
- Timely decisions. A week without an answer on a priority is a paid team week spent working blind.
Frequently asked questions
How much time do I need to put into the project as the client?
It depends on size, but the Product Owner usually needs several hours a week, more during demo and acceptance testing weeks. If nobody at your company can give that time, the project will slip.
What if I see something I don't like in the demo?
Say so right then. If it contradicts the acceptance criteria, it's a defect and gets fixed. If it's something new, it goes into the backlog as a change and gets prioritized against what's already planned.
Do I need to understand agile to work with a software company?
No. You just need to understand the rhythm: planning, development, demo and adjustment, every two weeks. The vendor should explain at kickoff how they work and what they expect from you.
Before your next project starts
If you're about to hire a development team and want to know what working together would look like, week by week, let's talk. At Disrupsoft we design and build custom web and mobile applications, and we stay in constant communication with your team throughout the project. Take a look at our custom software development service.
