Software development & publishing
FINDMYBALANCE LTD develops software for business tasks and domestic use, with software publishing as a distinct part of its activities. Bring a process that needs a better tool, or an application idea that needs definition.
Business applications
Illustrative workflow / open a stage
Identify required fields, who can submit information and what an incomplete entry should explain.
Define who can change a record, which decisions need recording and what a colleague sees when taking over.
Make the next action visible: a status change, a record to retrieve or information another system needs.
Business software can bring a defined sequence into one application: collecting a request, checking its details, recording a decision and showing what happens next.
Potential projects include internal workflow tools, structured record systems, operational dashboards and customer-facing applications. A useful brief turns operational questions into agreed screens, rules and outputs, considering connections to existing systems where needed.
Domestic software
Personal organisation tools, household records and planning utilities are possible project categories. Each starts with an individual’s task and the circumstances around it.
First use
Explain what to enter and what the application will do with it.
Repeat use
Consider suitable defaults and whether information needs to move between devices.
Recovery
Make mistakes understandable and show when an action needs attention.
Illustrative application behaviours; these examples describe possible work rather than a published product catalogue.
Agreed deliverables
A project should establish what will be produced, how each output will be reviewed and what constitutes acceptance.
A requirements brief defines the problem and boundaries. User journeys, interface designs or a prototype make behaviour easier to discuss.
Application code implements agreed functions. Integration specifications and test evidence can describe connections and checked behaviours.
Documentation explains setup, operation and relevant technical decisions. Scope should address source access, hosting accounts, dependencies and handover materials.
From idea to release decision
The sequence and depth depend on the project. Delivery stages and responsibilities belong in the written agreement.
Describe intended users, constraints and current difficulties. Turn these into a proposed scope with assumptions and unresolved questions.
Explore the main journeys before building. Review how an action begins, what changes and how the result is explained.
Translate agreed designs and rules into working software. Use reviews to resolve gaps and assess progress.
Verify agreed behaviours, including relevant failure cases. Bring together the application, configuration and operating information for a release decision.
Software publishing
A working application still needs decisions about distribution, access and presentation. Where publishing work is included, establish the required assets, account responsibilities and approval steps.
Describe what changed, its intended use and any relevant limitations.
Give users a useful explanation of significant differences.
Explain installation or access, prerequisites and the agreed distribution route.
Distribution channels, store acceptance and ongoing update arrangements need discussion and agreement.
Scope & tradeoffs
A compact tool and a connected application create different demands. Distinguish essential functions from possible later additions and record the assumptions behind that choice.
More roles require clearer permissions: who can see, create or change information, and under which conditions.
Integrations depend on external systems, available technical information and access. Define the purpose of each connection.
Offline behaviour changes how information is stored and reconciled when connectivity returns.
Sensitive information raises questions about access, retention and handling that should be considered early.
When a change is requested, identify its new behaviour, the existing work it affects and whether the delivery agreement needs to change.
Practical questions
An outline of the task, intended users and current difficulty can begin a discussion. Further definition may be needed before work can be scoped.
Describe the system and the changes required. Suitability depends on its technology, available access and condition.
Each connection needs a defined purpose, accessible technical information and an agreed place in the scope.
Maintenance, response arrangements and future development need their own agreed terms.
They depend on the work requested and should be confirmed in a project proposal.
Company record
A private limited company incorporated in England and Wales on 27 August 2026. Company registration number 17423665.
This website introduces those activities. Specific deliverables and commercial commitments are established through the scope and terms of an individual engagement.
Registered officeSUITE RA01, 195-197 WOOD STREET, LONDON, UNITED KINGDOM, E17 3NUStart with the task
Tell us who would use it, what they need to accomplish and whether an existing process or application is involved. Include important platforms, connections or constraints. Keep the first enquiry concise; leave out passwords, access credentials and confidential datasets.