Services
Seven ways
of working
Each service is described by its purpose, common use cases, example deliverables and a typical workflow. Scope and terms are agreed individually.
Custom software development
Applications written around one organisation's process instead of a generic product template.
To provide software where configuring an existing product would cost more, or constrain the work more, than building a system that matches the process directly.
Common use cases
- An operational process currently held together by spreadsheets and manual copying.
- A domain with rules too specific to express inside an off-the-shelf tool.
- An internal system that has outgrown the assumptions it was first built on.
- A product idea that needs a working, maintainable first version.
Example deliverables
- A documented domain and data model.
- A running application deployed to an agreed environment.
- Automated tests covering the core business rules.
- Technical documentation and a handover of repository access.
Typical workflow
- 01Clarify the process, its actors and its exceptions.
- 02Model the data and the state transitions explicitly.
- 03Agree scope, sequence and acceptance criteria in writing.
- 04Build in reviewable increments, each deployable on its own.
- 05Verify, document and hand over.
Web application development
Browser-based platforms with predictable state, durable data models and maintainable front-end code.
To deliver web systems that remain coherent after many rounds of change, rather than only working well at the first release.
Common use cases
- A customer-facing platform that must be fast, indexable and accessible.
- An internal dashboard consolidating data from several systems.
- A public site where content and metadata must be present in the initial HTML.
- A front end being rebuilt on top of an existing back end.
Example deliverables
- A responsive interface implemented from a shared design system.
- Clear separation of data access, business rules and presentation.
- Accessibility and performance considerations applied throughout.
- Deployment configuration and environment documentation.
Typical workflow
- 01Define the task flows and the screens they require.
- 02Decide rendering and data-loading strategy deliberately.
- 03Implement components against a consistent token system.
- 04Test flows, states and edge cases on real viewports.
- 05Deploy and document the operating setup.
Cloud architecture
Environments, deployment paths and infrastructure definitions that stay legible as systems grow.
To make it obvious what runs where, how it is deployed and how it can be changed safely, without depending on undocumented knowledge.
Common use cases
- A system deployed manually that needs a repeatable path to production.
- Environments that have drifted apart and no longer reproduce defects.
- Costs or performance that need to be understood before they are changed.
- A move from a single server to a structured, observable setup.
Example deliverables
- Infrastructure defined in code with separate environments.
- An automated build and deployment pipeline.
- Logging, metrics and error reporting sufficient for diagnosis.
- A written description of the architecture and its operational procedures.
Typical workflow
- 01Inventory the current infrastructure and its dependencies.
- 02Define target environments and the boundaries between them.
- 03Codify infrastructure and deployment.
- 04Add observability and verify recovery procedures.
- 05Document and hand over operational responsibility.
System integrations
Reliable connections between internal tools and third-party services, with explicit contracts.
To let separate systems exchange data correctly, with predictable behaviour when one of them is slow, unavailable or returns something unexpected.
Common use cases
- Data re-entered by hand between two systems that do not talk to each other.
- A third-party API that needs to drive an internal process.
- Webhooks and scheduled synchronisation between platforms.
- A legacy system that must keep running while new components are added.
Example deliverables
- Documented data contracts and field mappings.
- Validation, retry, idempotency and failure-handling logic.
- Monitoring and alerting on integration health.
- Runbooks describing what to do when a link fails.
Typical workflow
- 01Map the data on both sides and agree the canonical form.
- 02Define the contract, including error and partial-failure cases.
- 03Implement with validation and safe retries.
- 04Test against realistic and deliberately broken payloads.
- 05Instrument, document and monitor in production.
Business process automation
Rule-based, repetitive work moved into software so that people handle exceptions instead of routine.
To reduce manual effort and transcription error in processes that follow consistent rules, while keeping human judgement where it is genuinely required.
Common use cases
- Recurring reports assembled by hand from several sources.
- Approval chains tracked through email threads.
- Document generation, validation or routing done manually.
- Scheduled tasks that currently depend on someone remembering them.
Example deliverables
- A documented map of the process before and after automation.
- Automated steps with logging and an auditable history.
- Defined exception paths routed to the responsible person.
- Operating instructions for the people who supervise the process.
Typical workflow
- 01Observe and document how the work is done today.
- 02Separate deterministic rules from human decisions.
- 03Automate the rules and surface the exceptions clearly.
- 04Run in parallel with the manual process to compare results.
- 05Switch over, monitor and refine.
UI/UX design
Interfaces organised around the decisions users make, supported by a consistent design system.
To make software understandable at the moment of use, and to keep a product visually and behaviourally coherent as it grows.
Common use cases
- A product whose interface has accumulated inconsistent patterns.
- A complex workflow that needs to be made comprehensible.
- A new application requiring an interface structure before development.
- An existing system with accessibility or readability problems.
Example deliverables
- Documented task flows and screen structures.
- A design system covering type, spacing, colour and components.
- Specified empty, loading, error and permission states.
- Accessibility notes covering contrast, focus order and motion preferences.
Typical workflow
- 01Identify the decisions each user makes inside a task.
- 02Structure screens around those decisions.
- 03Establish the token and component system.
- 04Review flows against realistic content and data volumes.
- 05Hand over specifications alongside implementation.
Maintenance and technical support
Continued care for systems in production: updates, corrections, monitoring and incremental improvement.
To keep a running system secure, current and understandable after the initial delivery, and to respond in a structured way when something goes wrong.
Common use cases
- A delivered system that needs dependency and platform updates.
- An inherited codebase with no current maintainer.
- Recurring defects that need diagnosis rather than repeated patching.
- Gradual improvement work alongside normal operation.
Example deliverables
- A maintained dependency and platform update cadence.
- Diagnosed and corrected defects with regression tests.
- Monitoring and reporting on system health.
- An updated record of architecture and operational procedures.
Typical workflow
- 01Read the system and its deployment before changing anything.
- 02Establish monitoring and a baseline of current behaviour.
- 03Triage issues by impact and reproduce them before fixing.
- 04Apply changes in small, reversible increments.
- 05Keep documentation aligned with the running system.
Defining an engagement
Services are combined as a problem requires; most work involves more than one of the areas above.
Scope, sequence and terms are agreed in writing before development begins. Enquiries: VEWAI LTD — jamamcnulty105@gmail.com — vewaigroup.com