Services
Software, from interface to handover.
Mobile apps, web tools, AI features and product design. Each engagement starts with a written scope.
Mobile Apps
What we do
We design and build iOS and Android applications around the conditions in which they will actually be used. That includes unreliable connections, interrupted sessions, declined permissions and the difference between a quick task and a long form. Discovery establishes the essential journey before a platform or implementation approach is chosen.
Native and cross-platform approaches have different constraints. We would compare device access, background behaviour and maintenance needs against the product's scope. A shared interface is useful only when it still behaves appropriately on each platform. Offline requirements belong in that decision from the beginning, together with a policy for synchronisation and conflicts.
What you receive
The agreed delivery includes source code, a runnable application, setup instructions and documentation for the supported journeys. Device permissions, loading and error states are part of the interface. The handover also identifies account ownership, release configuration and any known limitations, so the next person can understand what has been delivered.
App-store preparation belongs in the scope discussion. Submission materials, review responses and testing responsibilities should be agreed explicitly. Approval remains an external process; a development milestone does not guarantee a store decision.
Timing
The schedule is set during Scope and expressed in weeks, with weekly builds available for review. A focused journey and a product with background capture or complex synchronisation need different plans. We confirm dependencies and acceptance criteria before committing to a delivery window.
Not included
Brand identity, marketing campaigns, hardware procurement and indefinite operational support are outside this service. Store accounts and external services must have clear ownership. Ongoing maintenance is a separate scope, and any change to the agreed feature set is discussed before it enters the build.
Working toolkit
Current preference, not a requirement. If the product already lives in another native stack, we will say whether we can work in it.
- Swift and SwiftUI for iOS when the product is native on Apple devices.
- Kotlin and Jetpack Compose for Android when Android needs equal weight.
- React Native with Expo when a shared interface is the better trade.
- SQLite for on-device storage, with a sync layer designed per product rather than assumed.
- App Store Connect and Google Play Console for release, in accounts you own.
Web Apps & Internal Tools
What we do
We build the software used between a request arriving and the work being finished: shared queues, admin panels, operational dashboards and focused web applications. We begin with the current workflow, including the spreadsheet or conversation that already makes it function. A new interface should remove a specific obstacle rather than create another place to maintain the same information.
The scope identifies who may see and change each record, where the data originates and what happens when an action fails. Search, filtering and status changes should be understandable without a training manual. Permissions and audit requirements are design inputs, not details postponed until the interface looks complete.
What you receive
Delivery includes the application source, the agreed data model, setup instructions and a working version of the supported workflows. We document roles, integrations and operational dependencies. Where history matters, the scope defines which changes are recorded and how someone can inspect them.
The handover should make ordinary administration possible without returning to the original developer. We identify account owners, explain the release process and record known limitations. Data import, export and recovery procedures are included when they are agreed parts of the project.
Timing
We establish a schedule in weeks during Scope and share weekly builds. The delivery window depends on the breadth of the workflow, access to existing systems and the condition of source data. Dependencies are written down before a milestone is treated as a commitment.
Not included
This service does not automatically include replacing an entire business system, cleaning an undefined historical dataset or operating a permanent support desk. Content entry, migration and additional integrations need explicit boundaries. If the existing spreadsheet already solves the problem, we will say so before proposing an application.
Working toolkit
These are the tools we reach for first. If you already run a different server stack, that is a scope conversation, not an automatic no.
- TypeScript as the default language on both the interface and the API.
- React for application interfaces.
- Node.js for the server, with PostgreSQL for data that has to stay consistent.
- Vite for a focused internal tool; Next.js when server rendering or file-based routing is the simpler shape.
- Hosting on a named service with an account you own — a VPS or a managed Node host, or whatever you already run.
AI Features
What we do
We integrate language models, transcription and document understanding into an existing product or an agreed new workflow. The starting point is the decision or task a person needs help with. We identify the source material, the intended output and the point at which a person must check the result before choosing a model or provider.
An integration has to handle incomplete inputs, uncertain answers and service failures. We design those states alongside the successful path. Structured output can make a response easier to process, but it does not make the underlying statement true. Review gates and source references should match the consequences of getting something wrong.
What you receive
Delivery includes integration source code, documented configuration, the agreed interface and an evaluation set built from authorised material. The handover explains prompts or schemas, provider dependencies, failure handling and the limits established during evaluation. Credentials belong in accounts with clear ownership, outside the source repository.
Where a human decision is required, the product should distinguish a generated draft from an approved record. We define how a reviewer corrects or rejects an output and what happens next. External actions require an explicit path rather than being an accidental side effect of generation.
Timing
The schedule is agreed in weeks during Scope, with weekly builds for review. Access to representative material and agreement on acceptable behaviour shape the delivery window. An evaluation milestone comes before a commitment to a wider integration when the model's suitability is still uncertain.
Not included
We do not promise error-free answers, unattended judgement in consequential workflows or ownership of third-party model behaviour. Foundation-model training, unrestricted data collection and indefinite prompt maintenance are outside this service. New providers, additional document types and external automations require an agreed extension of scope.
Working toolkit
We call hosted model APIs rather than training a foundation model. Provider choice is yours; credentials sit in accounts you own.
- OpenAI and Anthropic APIs for language.
- A Whisper-class model for speech-to-text.
- JSON Schema for structured output, so a draft is a record a person can check, not a block of prose.
- TypeScript on the product side, so the review interface, the schema and the model call live in the same codebase.
- Evaluation against a small, authorised set of examples before anything is wired into a live workflow.
Product Design
What we do
We design interfaces and interactions as working front-end code. The aim is to make the product's behaviour reviewable while changes are still manageable: what happens after a click, how a form explains an error and whether a task works on a narrow screen. The work begins with the journey and the information needed to complete it.
A visual system should support that journey rather than compete with it. We establish typography, spacing, components and states together. Keyboard access, readable contrast and responsive behaviour belong in the design itself. A polished default screen is incomplete if empty, loading and error states remain unexplained.
What you receive
You receive runnable front-end source, reusable interface components and notes that explain the intended behaviour. The agreed journeys can be opened and clicked, with illustrative data clearly distinguished from connected functionality. Component states and layout rules give an engineering team a concrete basis for integration.
We document the boundaries of the work, including which interactions are local and which require a backend. The handover records unresolved questions and known limitations. This makes a prototype useful for decisions without presenting it as a finished application or concealing the engineering still required.
Timing
We agree a schedule in weeks during Scope and provide weekly builds. The delivery window depends on the journeys being explored, the existing visual system and the review process. We identify who can make decisions and which dependencies must be available before committing to milestones.
Not included
Brand naming, identity design, illustration campaigns and ongoing advertising are outside this service. Backend implementation and research recruitment are included only when explicitly scoped. We do not treat an interactive study as evidence of user validation; that requires a separate, agreed research process with appropriate participants.
Working toolkit
The deliverable is working front-end code, not a folder of static screens. If a drawing helps a conversation, it is a scratchpad.
- HTML and CSS as the baseline — including the visual tokens, which are CSS custom properties.
- TypeScript when the interface has real behaviour to prove.
- React when the study needs state, routing or repeated interaction; otherwise the interface is plain HTML and CSS.
- Keyboard access, readable contrast and narrow screens belong in the same codebase, not a later pass.