Our Process

Our process is designed to reduce uncertainty. From the first conversation through deployment and support, each phase has defined outcomes so you know what to expect, what we need from you, and when decisions need to be made.

Overview

Software projects fail most often when scope is vague, assumptions go unspoken, or feedback arrives too late. Small Pea Software structures delivery in four connected phases: discovery and scoping, design and architecture, development and testing, and deployment with ongoing support. The phases are not rigid bureaucracy — smaller engagements may move through them quickly, while larger systems may revisit design as new requirements emerge. What stays constant is the discipline of agreeing what is being built before it is built.

You remain involved at the points that matter. We do not disappear for months and return with something that only partly matches your expectations. Regular checkpoints, written records of decisions, and staged delivery keep the project aligned with your operational needs.

Project planning board with development milestones
Each project follows agreed milestones so progress is visible and reviewable throughout delivery.

Phase 1: Discovery and Scoping

Every engagement begins with understanding your objectives, current tools, pain points, and constraints. We review how work is done today — often through spreadsheets, email, legacy systems, or a patchwork of disconnected platforms — and identify what the new or improved software must achieve. This phase produces a scope document that describes deliverables, assumptions, exclusions, timeline, and dependencies.

Discovery is not a sales exercise. It is where we determine whether the project is feasible within your budget and timeframe, and where you determine whether our approach fits your expectations. If the scope is not yet clear enough to estimate, we may propose a short paid discovery engagement to produce a detailed specification before full development begins.

What We Establish in Discovery

  • Business objectives and success criteria for the software
  • Users, roles, and permission requirements
  • Data sources, integrations, and migration needs
  • Technical constraints, hosting preferences, and compliance considerations
  • Deliverables, milestones, and acceptance criteria

Phase 2: Design and Architecture

Once scope is agreed, we define how the system will work and how it will be built. User flows describe the paths staff or customers will follow. Data models define what information is stored and how it relates. Technical architecture covers hosting, security, integration points, and the technologies chosen for the project. For user-facing systems, we may produce wireframes or screen outlines so stakeholders can confirm the approach before development consumes the bulk of the budget.

Design decisions are documented and shared for approval. Changes at this stage are far less costly than changes deep into development. We flag trade-offs explicitly — for example, where a simpler approach meets current needs but may limit future flexibility — so you can choose with full information.

Agreeing architecture and user flows before the build phase proceeds protects both your budget and our ability to deliver on time.

Phase 3: Development and Testing

Development proceeds in structured stages aligned with the agreed milestones. We implement core functionality first, then layer integrations, reporting, and refinements. Code is written for maintainability: clear structure, sensible naming, and documentation where the logic is not self-evident. We test critical paths — the workflows your staff will use daily — as well as edge cases that could cause data errors or security issues.

You receive progress updates at agreed intervals and opportunities to review working software before the final release. Feedback during development is welcomed; scope changes are handled through a change process so that additions are acknowledged and, where necessary, quoted before work proceeds.

  1. Environment setup — development, staging, and production environments configured with appropriate access controls
  2. Core build — primary workflows, data models, and user interfaces implemented against agreed specifications
  3. Integration work — connections to external systems, APIs, imports, and exports completed and validated
  4. Testing and review — functional testing, user acceptance support, and defect resolution before release

Transparency During the Build

You will always know what stage the project is at and what is coming next. We do not treat development as a black box. If a technical obstacle arises — an API limitation, a data quality issue, an unforeseen dependency — we raise it promptly with options rather than quietly working around it.

Phase 4: Deployment and Support

Release planning covers data migration, user access setup, hosting configuration, and any cutover steps needed to move from old processes to the new system. We assist with deployment to your chosen environment — whether cloud-hosted or on infrastructure you manage — and provide handover documentation so your team understands how the system operates.

After go-live, a warranty period covers defects in delivered functionality. Beyond that, we offer ongoing maintenance and support arrangements for fixes, security updates, dependency maintenance, and agreed enhancements as your business evolves. Software that is never updated slowly becomes a liability; we design for continuity.

User Acceptance Testing and Acceptance Criteria

Before release, you participate in user acceptance testing against criteria defined during discovery and refined in design. Acceptance criteria describe observable behaviour — what a workflow must do, what data must appear, what permissions apply — not vague intentions like "user-friendly." We provide a staging environment, test scenarios covering critical paths, and a structured period for your staff to validate the system against real operational tasks.

UAT is most effective when the people who will use the software daily are involved, not only project sponsors. We support defect logging during UAT, prioritise issues that block acceptance, and distinguish between defects (behaviour that does not match agreed criteria) and change requests (new or altered requirements). Sign-off at the end of UAT confirms the delivered system meets documented scope and triggers final milestone invoicing and production deployment.

Post-Go-Live Hypercare

The first weeks after production deployment receive heightened attention. During hypercare — typically overlapping with the warranty period — we monitor for issues that only surface under live load: data migration edge cases, integration timing, permission gaps for roles not represented in testing, and staff questions as workflows change. Response times for blocking defects are prioritised during this window.

Hypercare is not unlimited feature development. It focuses on stabilising delivered functionality and supporting your team through cutover. We document issues resolved, any workarounds agreed, and recommendations for the first support period. When hypercare concludes, transition to a standard maintenance and support arrangement — or internal handover — is planned so there is no gap in coverage.

What We Need From You

Successful delivery depends on timely input from your side. That includes access to subject-matter experts who can explain workflows, sample data for testing, decisions on scope questions, and review of deliverables within agreed timeframes. Delays in feedback or approvals affect timelines; we communicate openly when dependencies on your end are holding progress.

If you are replacing an existing system, we will need clarity on what data must be migrated, what historical records are required, and when the old system can be decommissioned. These details are captured during discovery but often require ongoing confirmation as the project progresses.

Software testing and quality review session
Testing focuses on the workflows your team relies on every day, not only demonstration scenarios.

Engagement Models Within the Process

The same process applies whether you are commissioning a new application, extending an existing system, or engaging us for a focused integration. The difference is scale: a small integration may complete discovery and design in days, while a multi-module platform may require several weeks of specification before development begins.

For ongoing work — support retainers, incremental feature development, or consulting on architecture — we adapt the process to a lighter rhythm: regular check-ins, prioritised task lists, and documented outcomes for each period of work rather than a single release milestone.

Start With a Conversation

Describe what you need to build or improve. We will outline how the process would apply to your situation and what the first step looks like. Contact us at support@smallpeasoftware.com or visit our Engagement Options page to learn how projects are structured commercially.

Related Pages

  • About Us — who we are and how we approach software delivery
  • Example Projects — representative types of systems we build
  • Engagement Options — project delivery, support, and consulting
  • FAQ — answers to common client questions