What would you like to build?
A new idea. A complex workflow. A system that needs to work better. We’d like to hear about it.
Tell us a little about your project.
Share what you’re working on and what a better solution would mean for your team.
Tell us which team or business process needs software, who will use it, and where the current workflow becomes difficult. Include the tools or spreadsheets you use today.
Describe the records, reports, calculations, and integrations you need, along with any access or data migration requirements. If you have a target launch date or budget range, include it so we can discuss a practical scope.
Use the form to share your project and a contact email. The next step is to clarify the requirements and agree on the scope before planning the work.
Planning the first conversation.
A useful project brief explains the decisions and working details behind the requested features.
Start with the first version of the system. If several teams have different requests, identify the workflow that needs attention first and the records it depends on. A useful starting point might be production planning, a sales pipeline, or restaurant table orders. Explain what has to work from the beginning and which improvements could follow later, so the conversation can establish priorities rather than treat every feature as equally urgent.
Bring an example of an ordinary working task. Describe what starts it, which person acts next, what information changes, and how the task ends. For manufacturing, that could mean taking a required output quantity through material planning and recording the result. For a sales team, it could mean moving an enquiry through the pipeline. These examples help connect requested screens to the decisions people need to make during the day.
Think about the information the software must use. List the types of records already kept in spreadsheets or other applications, who maintains them, and which reports rely on them. If two systems need to exchange information, describe the direction of that exchange and when it should happen. Existing exports, record layouts, and report examples can help explain the requirement without assuming that an integration has already been agreed or built.
Consider how responsibilities differ between users. Someone entering an order may need a different view from someone reviewing costs or maintaining company records. Tell us which actions need review, which information belongs to a particular team, and where departments need to share the same record. These details give the discussion a practical basis for access rules, approval steps, and the views that each role needs to carry out its work.
Describe how your team would recognize a useful first release. Choose a few normal tasks and the results you would expect to see, including the reports or calculations used to check them. Note any dependencies such as source data, access to another system, or a preferred deployment environment. We can use that information to discuss scope, questions that remain open, and the preparation needed before the software enters everyday use.