Before you request custom software: how we shape a proposal

A useful proposal connects a business problem to a clear first scope, an investment, and responsibilities on both sides. Before choosing features or technology, we need to understand the work your team is trying to do.

This guide explains what we consider, what you can prepare, and the decisions we work through together. It is for business owners and teams evaluating a custom application, an internal tool, or a more connected way of working.

You do not need a technical specification to start. A concrete problem, an example of the current process, and the people who understand it give us a useful starting point.

Start with the work your team needs to do

Our aim is to remove slow, disconnected steps that get in the way of the business. That may involve building software, connecting existing tools, or automating part of a process. The solution follows the need.

We consider the current setup before proposing something new. We look for a first version that completes a useful workflow, with an interface people can understand and clear places for review or human decisions.

The work is collaborative. We bring design and development; your team brings knowledge of the process, the exceptions, and what a useful outcome looks like. That knowledge shapes the proposal and the decisions during the project.

How we work toward a proposal

If you already have a sufficiently detailed specification, we can begin with feasibility. In most cases, an introductory conversation helps us understand the process and identify what needs to be defined.

1. Understand the process and objective. We discuss who does the work, what slows it down, which tools are involved, and what should improve.
2. Define the first scope and user experience. We work through the core workflow, users, permissions, connections, and UI/UX. We separate the first release from later additions.
3. Identify constraints and open questions. Existing data, access to systems, exceptions, and operating needs can affect feasibility and the work required. Questions that still need investigation should be visible.
4. Clarify the proposed work. The proposal needs to explain the scope, assumptions, exclusions, investment, and responsibilities. Conditions for delivery and subsequent services are agreed for the project.

The depth of this preparation varies with the project. The initial conversation is a starting point; it does not automatically establish a final price or settle every requirement.

Start with the first complete process

Before assigning a budget to “a portal” or “an internal tool,” describe the job it must complete. For example: a customer submits a request, a staff member reviews it, an owner is assigned, and the team records the outcome.

Then identify the decisions that affect the estimate. Will customers sign in? Does information need to move to another system? Can a request be changed after approval? Must old records be imported?

These are requirements to resolve before comparing prices. Ask for a proposal that separates:

• The first release: the agreed workflow, users, screens, data, and connections.
• Open questions: assumptions that need investigation before the work can be estimated confidently.
• Operation after launch: the services and responsibilities needed to keep the software running.
• Later additions: useful improvements that can be evaluated separately from the initial release.

This makes it possible to discuss a smaller first scope without confusing it with a lower price for the same work.

What changes the cost of a custom software project?

Consider a request to “build a customer portal.” That description leaves several decisions open. Can customers only view a status, or also upload documents, invite colleagues, change a request, and approve work? Does each action update another system? What happens when information is incomplete?

Those decisions turn a broad idea into work that can be estimated:

• The workflow and its exceptions. Define what starts the process, the steps that follow, and how cancellations, missing information, and changes are handled.
• Users and permissions. Identify who can see, edit, approve, or export information, including which customer’s records each person can access.
• UX and UI. Specify the tasks people need to complete and the screens that support them. A concise interface still needs decisions about forms, states, feedback, and navigation.
• Connections to existing tools. Establish what must move between systems, in which direction, how often, and what should happen if a connection fails.
• Existing data. Inspect the records to be imported, including duplicates, missing fields, attachments, and inconsistent formats.
• Operating requirements. Agree on supported devices, access controls, performance needs, testing, deployment, and responsibilities after launch.

A proposal becomes easier to evaluate when these assumptions are written down. “Includes an integration” is less useful than describing the records exchanged, the permitted actions, and the handling of failed updates.

Compare the scope before comparing the price

The following scenarios are illustrative planning examples. They describe possible first versions, their assumptions, and what would require a separate assessment. They are not priced packages or quotations.

1. One internal workflow

Example: a small team records incoming requests, assigns an owner, updates the status, and exports a list for a weekly review.

First version: browser access for one business, a request form, a shared list, agreed staff permissions, and a basic export. Assume existing data arrives in one agreed format and no external system needs to stay synchronized.

Outside this scope: customer accounts, offline work, a mobile app, advanced reporting, and ongoing two-way connections. Importing years of inconsistent records or adding several approval paths would need a separate assessment.

2. A customer-facing portal

Example: customers sign in to submit a request, upload documents, and see progress. Staff manage the same request internally.

First version: customer accounts, access to each customer’s own records, uploads, agreed status updates, and staff review. Define file limits, notifications, and account recovery before estimating.

Outside this scope: payments, electronic signatures, customer-managed teams, and synchronization with an accounting system. Each addition introduces its own user paths, permissions, and failure cases.

3. A platform with several roles and connected systems

Example: an operations team assigns work to field staff, managers review completion, and approved records move to another business system.

First version: role-specific screens, assignments, a review step, a defined integration, and an agreed migration plan. Clarify which system owns each record and how updates are reconciled.

Outside this scope unless specified: offline synchronization, multiple customer organizations, billing subscriptions, and a broad reporting suite. These requirements change the project substantially even when the initial screens look similar.

A useful first release completes a real process. Choose what can wait without leaving the team dependent on an unfinished handoff.

Budget for delivery and the work after launch

Separate the cost of delivering the first version from the cost of operating and changing it. Ask the proposal to identify these items:

Choose the same planning period when comparing running costs. A monthly hosting amount and a development total describe different commitments; neither explains the full first-year budget by itself.

At Bisanti, hosting, maintenance, and support can be arranged case by case, including through our collaboration with TechToYou LLC. They are agreed separately from software development. The project proposal should make the responsibilities and costs clear.

Could existing software or automation be enough?

Before commissioning a new application, describe what your existing setup cannot do.

• Consider an existing product when its workflow already fits the job and configuration is enough. Compare subscription costs, permissions, data export, and the work required to adopt it.
• Consider integration or automation when the main problem is moving information or advancing tasks between tools you already use. Check access, system capabilities, and exceptions before assuming they can be connected.
• Consider custom software when the team needs its own workflow, screens, shared records, or permissions that the available setup cannot support adequately.

These approaches can be combined. An internal application might keep an existing accounting tool and automate a defined handoff instead of replacing everything.

Explore workflow automation services →

Questions to ask when comparing proposals

Give each provider the same starting information, then compare their assumptions alongside the total.

1. What does the first version include? Ask for the workflows, users, screens, connections, and explicit exclusions.
2. How will we accept the work? Define the expected behavior, review process, and treatment of defects or unmet requirements.
3. What is fixed and what is estimated? Clarify the pricing model, uncertain items, and how changes affect the budget.
4. Who handles data and launch? Identify responsibility for cleanup, imports, account setup, deployment, and staff handover.
5. What do the ownership and license terms cover? Confirm rights to the custom deliverables, source-code access, third-party components, and what happens if you change providers.
6. What happens after delivery? Separate any agreed defect correction, maintenance, hosting, support, and new feature work.

A lower total may reflect a smaller scope or more work left to your team. A higher total also needs a clear explanation of the additional work it covers.

What to include in a request for an estimate

You do not need to solve the technical questions yourself. Bring what you know about these six points; we can work through the gaps together:

1. The process. What starts it, what happens next, and what marks it complete?
2. The people. Who uses the system, and what does each person need to do?
3. The current setup. Which tools, spreadsheets, inboxes, and documents are involved?
4. The information. What records already exist, what needs to move, and who can provide access?
5. The difficult cases. Where do people repeat work, correct mistakes, wait, or take over manually?
6. The first useful result. What must the initial release accomplish, and how will the team check that it does?

Include an example of a typical request or record with sensitive information removed. If timing or investment limits will affect the scope, explain them so the proposed first version can be evaluated against those constraints. It also helps to identify who can explain the process, review decisions, and provide access to the relevant tools or information.

Is this the right starting point for your business?

This approach is useful when you can point to a business process that needs to work better and want to define a solution around it. Your team does not need every answer at the start, but someone who knows the work needs to participate in shaping and reviewing it.

If you are still exploring whether the problem needs new software, say so. We can begin by understanding the situation and assessing the available approaches.

If you have a detailed specification, we can start by assessing feasibility. If you are still defining the need, an introductory conversation can help clarify the process, objectives, and a useful starting scope.

Explore custom software development →

See the service, review an existing project, and describe what you need the software to help you manage.