Example Projects

Work

Representative Delivery Examples

The projects summarised here are representative of work Small Pea Software delivers for Australian organisations. Client names and identifying details are withheld; the scenarios, constraints, and outcomes reflect real delivery patterns rather than hypothetical case studies assembled for marketing.

We build operational software — portals, workflow tools, integration layers, and reporting systems — that staff use daily. Each example below links to a fuller description covering client context, problems faced, technical approach, challenges encountered, and measurable results. Figures are realistic: we avoid claiming transformational percentages unless they were observed and verified during handover.

What these projects share is method. Discovery precedes build. Integrations are planned with explicit system-of-record rules. Reporting aligns to decisions people make in recurring meetings. Support terms are agreed before go-live rather than improvised when the first urgent ticket arrives. That consistency matters more than any single technology choice.

Organisations come to us when off-the-shelf products force awkward workarounds, when legacy tools cannot support the next phase of growth, or when internal IT capacity needs a delivery partner who documents as thoroughly as they code. The systems below span logistics, field services, wholesale distribution, and regulated reporting contexts common across NSW and interstate operations.

These are not the only systems we build. They illustrate categories — unified operations portals, customer-facing service hubs, integration middleware, inventory control, compliance reporting, and dispatch scheduling — so you can see whether your scenario rhymes with something we have shipped before. If it does, a conversation about scope and sequencing is usually the sensible next step.

Each narrative describes trade-offs honestly. Not every integration was real-time; not every migration avoided parallel running; not every metric moved dramatically in month one. Sustainable software improvement rarely looks like a keynote slide. It looks like fewer duplicate spreadsheets, faster approvals, and staff who trust the numbers on screen.

Technical stacks vary by client constraints: existing identity providers, vendor API maturity, hosting preferences, and internal skill profiles all influence architecture. We favour maintainable choices over fashionable ones — clear module boundaries, tested integration adapters, and deployment pipelines your organisation can operate after handover.

Select a project card to read the full narrative including architecture notes, delivery challenges, and post-launch metrics where available. If you would like to discuss a similar initiative, contact us with a short description of your current systems and the operational outcome you need.

We treat these examples as reference points for conversation, not a catalogue of fixed products. Your environment will differ — different ERP constraints, identity providers, regulatory obligations, and internal approval cultures all influence design. The value in reading another organisation's pattern is recognising which problems are universal and which require bespoke treatment.

How We Scope Similar Projects

When a brief resembles one of the examples below, we begin with a structured scoping conversation rather than assuming the same solution fits unchanged. We map your current systems, identify the operational outcome you need, and document assumptions before quoting. Scope documents list deliverables, exclusions, integration dependencies, and acceptance criteria so both sides understand what is — and is not — included in the first release.

Typical timelines vary by complexity. A focused integration or single-module tool often completes within four to eight weeks once requirements are confirmed. Multi-module portals with several integrations commonly run twelve to twenty weeks, depending on data migration, third-party API access, and how quickly stakeholders can review designs. We provide a timeline estimate in the scope document and flag dependencies that could shift dates — delayed vendor credentials, incomplete sample data, or extended approval cycles.

Clients who prepare well tend to move faster through discovery. Useful inputs include a short description of the problem, a list of systems the software must connect to, sample workflows or screenshots of current tools, and clarity on who will use the system and in what roles. You do not need a formal requirements document, but naming a subject-matter expert who can answer workflow questions within agreed timeframes materially reduces rework later.

If your situation shares characteristics with a project below — fragmented approvals, overnight batch files, field scheduling, or audit-ready reporting — read the full narrative first, then contact us with a brief outline of your environment. We will respond with observations on fit, likely sequencing, and whether discovery should precede a fixed quote.

Reading the Case Studies

Each linked project page follows a consistent structure: client context, problems faced, technical approach, delivery challenges, and outcomes where measurable. Pay attention to what was deferred to a later phase, how integrations were sequenced, and what the client needed to provide during build. Those details often matter more than the headline feature list when judging whether a similar approach would work for you.

Case studies are anonymised but grounded in delivery experience across NSW and interstate operations. They are not promises of identical results — your data quality, vendor APIs, and internal change capacity will shape outcomes. Use them to prepare better questions for any software partner, including us.