NOTES / PROCESS AND PROJECTS
Custom software: from problem to prototype
A digital project can begin with a simple sentence: I want to find a document, follow an order or make a handover clearer. Before choosing technology, that sentence needs to become observable. The Hands Studio process moves from the need to the journey, then through prototyping, development and verification. This note explains what each step needs and why a convincing screen alone is not enough to describe a product as ready for real use.
Describe the moment of difficulty
We ask what is happening when the difficulty appears. Who is working, which information are they looking for and what decision do they need to make? A concrete example is more useful than a list of features detached from context. With an order, the issue may involve entry, review or the transition into production. These are different moments involving different people and consequences. Identifying them helps choose an initial journey to observe and exposes questions that need answers before a solution is designed.
Separate the goal from the feature
“Having a dashboard” describes a possible interface rather than the underlying need. The goal might be identifying orders that require attention. That needs rules for recognising those orders and enough information to choose an action. A dashboard may help, but a simpler view might work too. Keeping the outcome separate from the feature prevents every early idea becoming a constraint. The initial scope should contain what is needed to test the journey, rather than every possible function someone can imagine adding.
Make the information explicit
An interface organises records, so we need to know what is available and what is missing. We define field meanings and how a record is identified. Two pieces of information with the same name can serve different purposes in different departments. Examples expose these differences before they become software rules. Demonstration records can support the initial discussion, preserving the problem structure while remaining clearly distinct from an operational archive. A sample screen should never be mistaken for evidence that an actual migration has already been completed.
Design the awkward states too
The journey does not end with the successful case. A search may find nothing, a field may be incomplete or an external service may fail to respond. A prototype should make those states understandable as well. People need to know whether an action completed, whether they should correct something or whether they can try again. This does not mean placing messages everywhere. It means choosing the information needed at the right moment and keeping button wording, actual behaviour and the displayed outcome consistent.
Use the prototype to ask questions
A visual trial supports discussion of sequence, hierarchy and terminology. It helps reveal whether the journey appears understandable and whether information is missing. Simulated behaviour must remain explicit, however. A drawn button does not establish successful delivery, and a sample list does not prove a database connection. Separating these levels makes the discussion more useful: each observation can become a decision or a subsequent check instead of creating expectations about features that do not yet exist behind the visible interface.
Choose technology for the case
Hands Studio projects demonstrate different choices: PHP and MySQL in VOLPE1943, Node.js and SQLite in MyNABI, and Apple tools in the games. The portfolio explains the relationship between a need and an implementation rather than recommending one technology for everything. Dependencies and external services also introduce maintenance, access and configuration constraints. Those conditions need to be understood before a choice is treated as final. The mere availability of a tool is not, by itself, a reason to add it to a project.
Write checks that match the work
For a feature, define an input, an action and an expected outcome. Verification may concern saved records, a generated document or keyboard navigation. Some checks are automated; others require a browser or a physical device. These are not interchangeable. A successful local test does not establish that the public domain has the same configuration. The final record should identify the environment checked and the limits remaining, so the person making a decision can understand the evidence without reconstructing the entire development conversation.
Prepare the next step
A useful first version has understandable boundaries. It separates completed work from assumptions and later features. Before release, content, access, responsibilities and outstanding checks need to be clear. A prototype is therefore a learning step rather than a shortcut around review. If you want to discuss software, start with a real activity and an example without confidential records. Our process and service pages provide references for turning that need into an initial scope, with the evidence required for deciding what should happen next.