AGILE / ITERATIVE SOFTWARE DELIVERY
PROPELOO delivers software via structured agile methodology — two-week sprints with working software demonstrated at the end of each, milestone-based contracts with transparent scope management, and daily delivery visibility without daily standups. Agile is not a process. It is a commitment to learning from working software faster than you can learn from specifications.
The most expensive software development mistakes are the ones discovered late. Requirements that seemed clear on paper turn out to be wrong when users interact with the first working version. Technical decisions that looked sound in an architecture document reveal their flaws when the system is under real load. Agile delivery — genuine agile, not agile in name with a waterfall heart — makes these discoveries in sprint three when the cost of correction is a week of rework, not in month eight when it requires re-architecture. PROPELOO runs genuine agile sprints: scope is prioritised into a backlog, two weeks of the highest-priority items are built and demonstrated, feedback shapes the next sprint. Requirements change via change orders that are documented and agreed — not silently absorbed until they cause delay.
Paid discovery sprint (5-10 days) producing: architecture document, data model, API design, technology stack justification, milestone plan and risk register. This becomes the contract baseline.
Two-week sprints with: sprint planning (scope agreement), daily async video updates, CI deployment to staging throughout, end-of-sprint demo with working software, sprint review and retrospective.
Prioritised product backlog with effort estimates, sprint capacity planning, dependency mapping and continuous refinement. Scope changes via change order, not silent accumulation.
Pull request code review standard, automated test coverage enforcement in CI, staging environment parity with production, and definition of done that includes tests, documentation and accessibility.
Shared delivery board updated daily, async video updates replacing status meetings, sprint demo recordings for async stakeholder review, and burn-up charts tracking milestone progress.
Intellectual property transfers to client at each milestone invoice — code, designs, documentation. No ongoing PROPELOO dependency. Fixed milestone prices with change order for scope changes.
Agile is not a license to avoid planning. It is a structured process for learning from working software faster than you can learn from documents.
A sprint that starts without agreed architecture and scope will spend the first three days making decisions that should have been made in discovery. Paid discovery (5-10 days) that produces an architecture document, data model and milestone plan is not optional overhead — it is the difference between a sprint team that executes and one that debates.
Axiom:
A sprint that produces 47 completed Jira tickets but no deployable software has not made progress — it has generated activity. Every sprint must end with software that can be deployed to staging and demonstrated to stakeholders. Tickets closed is a vanity metric. Working software is the only metric.
Axiom:
Every scope change that is not documented, estimated and agreed creates an implicit commitment that will eventually surface as a timeline dispute. Change orders are the mechanism that makes scope change visible and manageable. They protect both the client (no hidden work) and the engineer (no silent scope creep).
Axiom:
A sprint retrospective that produces one actionable change per sprint compounds over a project. Teams that do not retrospect make the same mistakes in sprint eight that they made in sprint two. The retrospective is not therapy — it is continuous process improvement.
Axiom:
Impact: 2-week sprints for most software projects. 1-week for discovery phases or design sprints. Kanban for ongoing maintenance and support work.
Impact: Fixed milestone price with change orders for scope changes. Client knows cost per milestone, change is managed transparently. Pure T&M creates incentive misalignment.
Impact: Linear for most product development teams. Jira for enterprise clients with existing Atlassian infrastructure. The tool matters less than the process.
Impact: Code complete + PR reviewed + automated tests passing + deployed to staging is the minimum acceptable definition of done for production software.
Impact: Async video updates (Loom or equivalent) daily replace synchronous standups. Live calls for sprint planning, demo and retrospective. Asynchronous by default reduces interruptions while maintaining visibility.
Impact: Production-identical staging (same infrastructure, smaller scale) is required for meaningful pre-production testing. Differences between staging and production create a class of bugs that only appear in production.
New SaaS product from discovery through MVP to growth features — milestone-based delivery with IP transfer at each milestone.
Legacy system modernisation via strangler fig pattern — new features built in modern stack, old system gradually replaced, continuous deployment throughout.
Ongoing development retainer for established product — sprint backlog management, 2-week feature delivery cadence and continuous architecture improvement.
Embedding PROPELOO engineers into an existing team — working within the client's agile process, sprint commitments and delivery standards.
Zero-to-MVP in 8-12 weeks — discovery sprint, architecture, core feature development and beta deployment with real users.
Parallel rebuild of an existing platform — new architecture running alongside old, feature parity verification before cutover.
Stack: Linear, Notion (documentation), GitHub Projects
Stack: Loom (async updates), Slack, Figma (design review), Miro (workshops)
Stack: GitHub, GitLab, Branch strategy, PR review standards
Stack: GitHub Actions, ArgoCD, Automated testing in CI, Staging deployment
Stack: Notion (ADRs), OpenAPI (APIs), README standards, Runbooks
Stack: PR review checklist, Coverage enforcement, Lighthouse CI, Accessibility audit
Automated dependency vulnerability scanning (Dependabot, Snyk) in CI pipeline. No PR merges with known critical vulnerabilities in dependencies.
No secrets in source code. Pre-commit hook scanning for accidental credential commits. Secrets injected via environment variables from a secrets manager.
Every PR reviewed by a second engineer before merge. Security checklist items: SQL injection prevention, input validation, authentication enforcement, logging of sensitive data.
Staging environment uses separate credentials from production. Staging never contains real production user data. Data masking for any production data copied to staging.
STRIDE threat modelling at the architecture phase for any system handling user data, payments or authentication. Threats documented as security requirements before implementation.
All code committed to client-owned repositories from day one. No PROPELOO intellectual property embedded in deliverables. Clean IP transfer without ongoing licence dependency.
Architecture, data model, technology selection, milestone plan and contract baseline.
Project scaffolding, CI/CD, staging environment, authentication and core data model.
Two-week sprints: planning → build → demo → retrospective. Working software every sprint.
Milestone gate: client accepts deliverable, milestone invoice issued, IP transfers.
Every commit to main deploys to staging automatically. Production on milestone approval.
Scope changes via change order: documented, estimated, approved before work begins.
Production deployment, runbook documentation, knowledge transfer and optional retainer.
Expected and welcome — via the change order process. Any change to agreed sprint scope or milestone scope is documented as a change order: what is changing, estimated effort impact, timeline adjustment and cost (if any). Agreed before work begins. This is not bureaucracy — it is the mechanism that keeps the budget visible and prevents silent scope creep from accumulating into disputes.
A paid 5-10 day discovery sprint produces: system architecture document (technology decisions with justifications), data model, API contract design, user flow diagrams, project milestone plan with effort estimates, risk register and definition of done. This document becomes the contract baseline and reduces scope risk significantly compared to going straight to development.
Daily async Loom video updates (3-5 minutes) from the lead engineer: what was built today, what is in progress, any blockers. Shared delivery board updated daily. End-of-sprint demo recording. This gives more visibility than a daily standup call while respecting the team's focus time.
The project is divided into milestones (e.g., Milestone 1: Authentication + Core Data Model, Milestone 2: Feature Set A). Each milestone has a fixed price. The milestone invoice is issued when the client accepts the deliverable. IP for that milestone transfers at invoice. Budget is predictable. Scope changes via change orders affect subsequent milestones.