App experience design
Structure the journey, content and interface states. Consider accessibility, feedback, and what happens when a person takes an unexpected route.
Think it through.
Build it well.
A development partner for ambitious software ideas with their feet on the ground. Product judgement, clear design and implementation belong in the same conversation.
One product. Four kinds of consequence.
167–169 Great Portland Street“Strategy is useful when it changes what gets built—and what gets left out.”London · W1W 5PF
Ambition needs a shape it can live in.
SOFTWARE AND CONSULTANCY LTD is a London digital development partner for people with a worthwhile software idea and a desire to make sound decisions about it.
An idea can feel complete in conversation and become less certain when it meets real users, operating conditions, data, budgets and the details of implementation. That is normal. The useful work is not to inflate the concept or dismiss it too early; it is to find out what the idea needs to become and what a credible first version might involve.
We bring product strategy and delivery thinking together. Strategy gives a team a reason to choose: who matters, which need is worth addressing, what the product should make possible and which assumptions deserve investigation. Implementation thinking asks how those choices might become a coherent interface, a dependable service and maintainable software. Keeping the two connected helps a plan stay practical.
Our service areas include mobile application development, app UX/UI design, website design and development, bespoke software engineering and integrations, plus app-store submission preparation. A project may need one discipline or several. A website is not automatically the right home for every idea; an app is not justified by the fact that an app can be built. The context should determine the form.
We work in clear stages of thought: understand, frame, test, design, implement and review. Those words are not a promise of a preset process or a fixed duration. The actual sequence depends on what is already known, who needs to be involved and where uncertainty can alter a decision. We aim to make the next choice understandable before asking people to commit to it.
“Ambitious but realistic” is not a contradiction. Ambition can mean a meaningful change for users, a distinctive service or a new way to join up work. Realism means taking account of operational ownership, third-party systems, accessibility, content, security obligations, release conditions and the capacity to look after what is made.
London contains organisations at every scale and with very different constraints. This company does not assume a particular sector, funding stage, audience or technical environment. We will need to hear the specifics before proposing an approach. A confident discussion can still include “we need to check that” when an answer depends on information not yet available.
This page introduces the company's areas of work and a considered way to approach them. It makes no claim to named clients, past launches, awards, success rates, years in business or completed project history. Outcomes, fees, availability and milestones need to be defined for the work under discussion rather than borrowed from a generic promise.
If your thought is still a sketch, start there. Tell us what prompted it, who might benefit and what you are unsure about. If your brief is already detailed, tell us which decisions are fixed and which should remain open. Either way, the conversation can begin with the substance rather than the polish of the pitch.
Richard James GourlayDirector, SOFTWARE AND CONSULTANCY LTD
02 / Development advisory
One product, several decisions.
We join the work at the point that makes sense: defining the experience, building the service or preparing for its next operational chapter. Select a discipline to prefill an enquiry.
01
DIRECTION / EXPERIENCE
Make the product legible.
Decide what it is for and how someone should move through it.
Website design and development
Give the site a clear purpose, coherent content, useful navigation and responsive implementation, with future ownership considered.
02
IMPLEMENTATION / ENGINEERING
Make the chosen thing work.
Connect product intent to buildable software and system behaviour.
Mobile application development
Build around essential tasks, platforms, data and the conditions in which the app will be used. Scope follows what the product needs, not a standard recipe.
Bespoke software engineering
Implement agreed behaviour with understandable structure, appropriate testing and room to change. Technical decisions depend on the actual requirements.
Software integrations
Connect services only after checking interfaces, permissions, data shape, provider terms and the behaviour needed when a connection is unavailable.
03
RELEASE / STEWARDSHIP
Prepare for real use.
Make the responsibilities and limits after implementation visible.
App-store submission preparation
Organise agreed materials and submission steps. A platform provider controls review, timing and acceptance; approval cannot be guaranteed.
Support for an existing product
Discuss the product, ownership and response expectations before defining any support scope. No support package or service level is implied.
03 / The working method
Strategy with its sleeves rolled up.
Ideas become more useful when the thinking is close enough to implementation to notice what it asks of people, systems and time. We use strategy to make choices—not to decorate a delivery plan with certainty it has not earned.
The first task is to understand the idea as a response to something. Which person is having difficulty? What are they trying to achieve? What do they do now, and what would make the experience meaningfully better? The answers may confirm the original concept, reshape it or suggest that a smaller intervention deserves attention first.
Next, separate the decisions. Some are product questions: which user or task comes first? Some are operational: who will own the service and keep its content current? Others are technical: what information must be stored, what systems need to connect and which constraints have not yet been checked? Making those categories visible prevents a technical preference from masquerading as a product decision.
“A useful milestone makes the next decision easier—not merely the status report longer.”
Then give the idea an inspectable form. A journey map, prototype, content outline or technical sketch can make trade-offs discussable. It is not a finished answer. It is a way to invite the right feedback while change is still manageable. People should be able to say what they recognise, what they cannot use and what is missing.
If implementation is appropriate, agree the pieces of behaviour that matter and how each will be reviewed. Include permissions, loading, error and empty states where relevant. Confirm what depends on third parties and who can make decisions when a dependency changes. Review should be part of delivery, not something postponed until a deadline creates pressure.
A release is a transition, not a magic finish. Handover should make relevant setup, responsibilities, known limitations and follow-on choices clear. App-store support can help prepare an agreed submission; it cannot control how a platform reviewer interprets policy or when a decision arrives.
Name the need
Describe the user, context and outcome before selecting a feature.
Question the leap
Identify assumptions that could change product direction or feasibility.
Make it discussable
Represent the experience in a form stakeholders can review and challenge.
Keep the edges in view
Consider data, permissions, errors, dependencies and maintenance.
Agree what done means
Use acceptance points connected to the need, not a vague sense of polish.
Can you help decide whether the idea is worth building?
We can discuss the need, intended users, assumptions and possible next steps as part of an agreed piece of work. The right investigation depends on what is known and what a decision requires. There is no automatic verdict from a short description, and no promise that a build will be recommended.
Do you work with an early-stage concept?
An early concept can be a useful starting point. Explain what prompted it, who it might help and what you currently believe. We can then discuss an appropriate scope for clarifying the product, design or technical questions; this does not imply a particular funding or company stage.
What does “strategy and implementation” mean here?
It means connecting product choices to design and engineering implications. The strategy conversation asks what is useful and for whom; implementation thinking considers how the agreed experience may be built, tested, operated and changed. The specific outputs must be agreed for each project.
Can you take over a project already in progress?
That depends on the current product, code, access, documentation, ownership, dependencies and desired outcome. A practical discussion should establish what can be reviewed and who has authority to provide it. No existing project is presumed to be ready for continuation.
How do you keep an ambitious scope realistic?
Make the intended outcome, essential journeys, risks, dependencies and operational ownership explicit. Distinguish the first useful release from later possibilities. A phased scope can be considered, but phases and dates must be based on the actual work and agreed capacity.
Can you design an app before choosing technology?
User journeys and interface direction can be explored before every technical detail is settled, while design should still respond to real constraints. Platform needs, data, accessibility, security and existing systems may change what is sensible, so product and engineering questions need to inform one another.
Do you guarantee app-store approval or timing?
No. App-store preparation can include materials and submission steps within an agreed scope. A platform provider sets its own requirements, review sequence, timing and acceptance decision, none of which can be guaranteed by this company.
What should I include if the brief is confidential?
Do not put confidential or sensitive material in this public enquiry form. You can describe the general kind of problem without revealing protected details, and note that you would like to discuss an appropriate way to share more. Any confidentiality arrangements need to be agreed separately.
05 / Milestones to agree
Progress with something behind it.
These examples describe possible future checkpoints and quality criteria. They are not a record of completed projects or a promise of a particular result.
A defined product question
The intended users, core need, constraints and unresolved assumptions are described well enough to guide an agreed next activity.
An experience people can challenge
A journey, prototype or design direction is available for stakeholders to assess against the tasks and conditions that matter.
Implementation checked against criteria
Agreed behaviours and important states are reviewed, with defects, known limitations and open dependencies made visible.
A handover with named next steps
Responsibilities, relevant documentation and future decisions are clear to the people expected to operate or extend the service.
06 / Notes for a better first conversation
Bring the useful unknowns.
Preparation should reduce confusion, not become a test of readiness. Use these short guides selectively; a half-formed idea is still welcome.
Write the idea as a change for one person
Try describing who is doing what today, what feels difficult and what they should be able to do instead. This shifts attention from a feature list to an outcome. If you have several audiences, write one version for each rather than blending their needs into an imaginary average user.
Sort facts, assumptions and questions
Mark what you have observed, what you currently believe and what you still need to find out. Include where each belief came from. This makes it easier to choose a sensible investigation and prevents estimates from quietly becoming requirements.
Separate the first useful release from the horizon
List the smallest set of tasks that would make an initial product useful, then keep later ideas in a separate list. This is not a promise that the first version will be small or quick; it is a way to discuss priorities and dependencies honestly.
Map the people behind a digital service
Consider who uses the product, who supplies content or data, who approves decisions and who handles day-to-day operation. These roles can overlap, but making them visible helps reveal where access, review or ownership needs agreement.
Bring the constraints you already know
Share relevant platform requirements, existing systems, contractual conditions, accessibility expectations, security obligations or dates that matter. Distinguish firm constraints from preferences. A constraint can be investigated; it should not be hidden until implementation.
Think beyond the happy path
Ask what a person sees when there is no content, a connection fails, an action is rejected or information is missing. Those moments often reveal product and engineering questions that a polished ideal journey does not show.
Decide who can accept the work
Identify who will review the deliverable, what evidence they need and who can make a decision if feedback conflicts. Acceptance points are only useful when participants understand their role and have access to the work being reviewed.
Make room for ongoing care
A digital product will need someone to manage content, access, user issues, updates and future changes. Ask who owns those duties and what skills or suppliers are available. Support should be discussed explicitly rather than assumed to follow a build.
07 / Availability
Business hours, without a mystery.
Reach out during the working week or leave a message whenever it suits you. Opening hours do not imply a guaranteed reply time, project availability or emergency cover.
Monday–Friday09:00–18:00 UK local time
SaturdayClosed
SundayClosed
A project schedule, review rhythm or support arrangement is agreed separately once the work and responsibilities are understood.
08 / Contact
Put the idea into words.
Tell us what led you here, who the idea is for and which part feels uncertain. There is no need to share confidential details in this form.
Company
SOFTWARE AND CONSULTANCY LTD
Address167-169 Great Portland Street, 5th Floor, London, England, W1W 5PF
Telephone
Open address in Google MapsThe embedded map needs optional map permission. You can use the address or open Google Maps without enabling it.
Prepare an enquiry
Your details stay in this page until you choose to prepare an email. Review and send it yourself; there is no automatic sending or server-side form saving.