Bespoke software.
Your questions answered.
Straight answers about choosing, commissioning and managing bespoke business software with StellarStacks.
Explore the questions below, from your first enquiry to integrations and handover. Project-specific costs, dates and responsibilities are confirmed in the agreed scope.
Choosing the right software · Systems, portals and integrations · Cost, timescales and the project process · Ownership, security and handover
Choosing the right software
What does StellarStacks do?
StellarStacks is a bespoke business software studio. We build management systems, business portals, dashboards, workflow automation and integrations around the way a business works. A project can be a single internal tool or a connected system that brings several processes together.
What is bespoke business software?
Bespoke business software is designed for a particular organisation’s processes and users. An off-the-shelf product offers a standard set of features to many businesses; a bespoke system is shaped around agreed requirements. The useful question is whether those requirements justify a custom build, rather than whether custom software sounds more impressive.
Do I need bespoke software, or would an existing product be better?
An existing product can be the right choice if it meets your needs without expensive workarounds. A better spreadsheet or clearer process may also be enough. Bespoke software is worth exploring when important processes need connecting, access needs differ between users, or repeated manual work creates a recurring problem. We discuss the alternatives before deciding what to build.
Can we start with one tool instead of a complete system?
Yes. A focused first project can address one job, such as managing records, handling requests or showing key information. We agree its boundaries and any connections it needs. Starting small can make the work easier to evaluate, provided the design also considers how it might connect to other processes later.
How do we choose the first process to improve?
Choose a task with a clear beginning, a useful result and a person responsible for it. Note how often it happens, where information is entered again and what causes delays. Agree a small first scope and a way to judge the result before adding other processes.
Does workflow automation need artificial intelligence?
No. Many workflows use explicit rules: route a request, check a date, send a reminder or require an approval. AI may be considered for less predictable material, such as free-text documents, but introduces additional checking, data-handling and cost questions. The task should determine whether it is appropriate.
Systems, portals and integrations
What is the difference between a management system, a portal and a dashboard?
A management system holds records and supports day-to-day tasks. A portal gives a defined group, such as customers, partners or staff, access to information and actions. A dashboard presents information for review and decisions. These can be separate tools or different parts of the same business system.
Can a portal give customers and staff different access?
A portal can be designed with different roles and permissions. The requirements should specify what each group can see, add or change, including which information must remain private. Permissions are part of the system design and need testing with realistic user scenarios.
Can software automate approvals and routine tasks?
Software can route requests, track their status, create reminders and pass work between people. The workflow must define its rules, exceptions and approval points. Tasks that need judgement should stay with an appropriate person rather than being approved automatically just because automation is available.
Can you connect our existing software?
We assess integrations as part of the project. Feasibility depends on the other product’s application programming interface (API), permitted access, licensing, data quality and security requirements. An API is a supported way for software systems to exchange information. We confirm what is possible before committing to a connection; compatibility is not assumed.
Can existing spreadsheet data be moved into a new system?
Data migration can be included in the scope after the files have been reviewed. Duplicate records, missing values and inconsistent formats may need resolving first. Agree which data should move, how fields map to the new system, and who will check the result. Migration effort depends on the condition and volume of the source data.
Can we keep the software that already works?
Often, a project can add a focused tool or connect an existing system rather than replace everything. The starting point is to identify what works, what causes difficulty and which connections are supported. Integration feasibility, licensing and access restrictions still need checking before a solution is agreed.
How should an automated workflow handle exceptions?
A workflow needs a defined route for incomplete information, failed connections and cases that fall outside its rules. Agree what gets recorded, who is notified and how the work is resumed or corrected. Repeating an action must not accidentally create duplicate records or send the same message twice.
Cost, timescales and the project process
How much does bespoke software cost?
The price depends on the agreed scope. User roles, workflows, integrations, data migration, testing and handover all affect the work involved. A useful estimate starts with the problem you want to solve and the essential first version. Development costs should be considered alongside hosting, licences and any ongoing support; those arrangements need to be clear before work begins.
How long does a software project take?
Timescales depend on the size of the system, the complexity of its connections and how quickly requirements and feedback can be agreed. A focused tool has a different scope from a system serving several teams. We agree a project schedule after understanding the work, including review points and dependencies rather than promising the same delivery time for every build.
Do I need a technical specification before enquiring?
No. Start with what happens today, the tools you use, and where the work slows down or becomes unreliable. Examples of repeated tasks, difficult handovers and missing information are useful. A finished feature list is not necessary for an initial conversation.
Tell us about your project or call 01722 632037.
How does the development process work?
Our approach covers four stages: map the current work, agree priorities, make the proposed solution tangible, and develop it with practical feedback. Screens and workflows are reviewed before their details are built. Testing uses realistic working scenarios, and documentation and handover needs are discussed as part of the project.
Will we be able to review the software during development?
Reviewing the proposed screens and workflows is part of our approach. Feedback helps check whether the system fits the people using it and the tasks they need to complete. The review stages, decision-makers and how feedback is gathered should be agreed for the project.
What happens if our requirements change?
Changes should be assessed against the agreed scope. A new requirement may affect cost, timing, integrations or work already completed. Agree the impact before adding it to development. Separating essential requirements from later improvements makes those decisions easier.
How can we judge whether the new system is helping?
Choose measures that relate to the original problem, such as time spent re-entering information, missed follow-ups or the effort needed to produce a report. Record the starting position and compare it with the same task after the system is in use. Results depend on the process and adoption; a fixed saving cannot be assumed.
What should we prepare for an initial project discussion?
A short walkthrough of one real task is useful: where it starts, who handles it, the systems involved and how completion is checked. Bring a list of the main difficulties and essential outcomes. Use anonymised examples initially; avoid sending passwords or sensitive live records through a general enquiry form.
Ownership, security and handover
Who owns the software and source code?
Ownership and rights to use the software and source code must be stated in the project agreement. Third-party components and services may have their own licence terms. Discuss the deliverables, repository access and any restrictions before development begins rather than assuming every project has identical terms.
How will access and sensitive information be handled?
Access requirements are considered during design: who needs which records, what each role can do, and which information should be restricted. Security also depends on hosting, authentication, integrations and ongoing administration. The controls required for your project need to be agreed and tested; a bespoke build does not automatically guarantee security or regulatory compliance.
What happens after the software is handed over?
Handover should make the agreed system understandable to the people who will use and manage it. Documentation, training needs, access arrangements and operational responsibilities are discussed as part of the scope. Hosting, maintenance and future support should be agreed separately where needed, including who is responsible for updates and issues.
Will the software work on phones and tablets?
Mobile and tablet use should be included in the requirements where relevant. Screen layouts, navigation and important tasks can then be designed and tested for those devices. A mobile-friendly website or portal is different from a dedicated mobile app, so the required experience needs to be clear.
Are the dashboard images examples of client projects?
No. The dashboard and portal visuals on this website are illustrative concepts with fictional demonstration data. They show possible ways to organise information; they are not client case studies, live systems or promises that every project will include the same features.
Can software help preserve knowledge when staff leave or are absent?
A system can organise working instructions, decisions, history and handover notes alongside the records people use. It still needs someone to keep that information current. Decide which knowledge matters, who maintains it and what a colleague needs to see to continue the work without relying on one person’s memory.
How should backups and recovery be planned?
Agree what needs backing up, how frequently, who manages the copies and how restoration will be tested. Recovery planning should cover both data and the services the system depends on. Hosting, backup and maintenance responsibilities must be included in the relevant agreement; they are not automatically the same for every project.
Have a question about your own business?
Tell us about the work you want to improve. Discuss your software project or call 01722 632037.