Start with the mess, not the software
The first step in a custom software project is not writing features down. It is pinning down the business problem in plain language, with the people who live it every day. If you skip that and go straight to demos, you get a prettier version of the same confusion, plus a bigger bill.
When people ask, What should I do first when planning a custom software project for my company?, they usually want a neat checklist. The real answer is less tidy and far more useful: first, decide whether you are fixing a broken workflow, a data problem, or a genuine software gap. Those are three different projects.
If you get that wrong, everything downstream gets noisy. Requirements expand. Stakeholders start arguing about edge cases. Vendors show you features you do not need. The scope slips, and nobody can explain why.
Run one internal meeting before you talk to anyone external
The first meeting should be a short, structured working session with the people who own the process, the data, and the commercial outcome. Not everyone. The right people.
For most B2B companies in Australia, that means:
- the operational owner of the process
- one person who feels the pain daily, often a team lead or power user
- someone who owns the data source, usually finance, systems, or ops
- a decision-maker who can approve scope and budget
- if integrations are involved, the technical lead or fractional CTO
If you leave out the person who actually touches the workflow, you will miss the ugly bits. If you leave out the owner of the data or the integration, you will discover the real constraint after the scope has already been sold to the board.
This meeting is not for solutions. It is for naming the problem clearly enough that everyone can agree on what “better” means.
If the first internal conversation cannot produce a shared problem statement, you are not ready for vendor demos.
Capture the pain first, then the workflow, then the data
Experienced teams do not start by listing features. They start with pain points, then map the workflow that produces them, then capture the data fields and integration constraints that shape the build.
That order matters.
1. User pain points
What is slow, manual, error-prone, or embarrassing right now? Where are people copying the same data twice? What gets escalated to a manager because the system cannot handle it?
This is where you find the business case. Not in a feature list.
2. Current workflow
Map the process as it exists today, not as people think it should exist. Include the handoffs, approvals, exceptions, spreadsheets, inboxes, and side conversations.
This is usually where the real cost sits. A lot of “software problems” are actually process problems wrapped in software language.
3. Data fields and rules
Once the workflow is clear, document the fields that move through it. Customer IDs, product codes, pricing tiers, approval limits, delivery dates, tax treatment, status changes, audit notes.
This is where custom software planning gets real. If a field is missing, duplicated, or inconsistently named, the build will feel broken even if the interface looks polished.
4. Integration constraints
Only after that do you map what the system must connect to, such as NetSuite, MYOB Advanced, Cin7, Xero, Salesforce, or a warehouse system. Integration constraints are not a footnote. They often define the shape of the project.
If you want the short version of What should I do first when planning a custom software project for my company?, it is this: document the pain, map the workflow, then check the data and integration reality before anyone starts sketching screens.
When departments disagree, do not start with a prototype
Conflicting opinions are normal. Sales says one thing. Operations says another. Finance says both are wrong.
When that happens, the right first step is usually process mapping, not a prototype. A prototype is useful when the team agrees on the problem and needs to test interaction or usability. It is the wrong tool when people are still arguing about what the process actually is.
Use this rough rule:
| Situation | Best first step | Why | |---|---|---| | Different departments describe the same workflow differently | Process mapping | Exposes where the disagreement is really happening | | The workflow is understood, but users hate the current experience | Stakeholder interviews | Surfaces friction and workarounds quickly | | The process is clear, but the team cannot picture the end state | Prototype | Helps validate screens, sequence, and usability | | The issue is data quality or reporting inconsistency | Data audit | Prevents building on bad source data |
A prototype too early can be dangerous. It feels productive, but it often locks people into a shape before the problem is understood. I have seen teams spend weeks reacting to a mock-up that was based on the wrong assumptions. That is expensive theatre.
The fastest way to tell what kind of problem you really have
At the very start of a custom software project, the quickest diagnostic is a simple three-part test:
- Can the current process work if people follow it manually?
- Does the process break because data is missing, inconsistent, or trapped in too many systems?
- Does the business need a new capability that no current tool can handle cleanly?
If the answer to the first question is yes, but nobody follows the process consistently, you may have a process discipline problem, not a software problem.
If the process is sound but reports are wrong, handovers fail, or teams are rekeying the same information, you probably have a data problem.
If the business genuinely needs a workflow that off-the-shelf software cannot support, such as customer-specific pricing, approval logic, or ERP-linked ordering, then you are in custom build territory.
That distinction matters more than most people realise. It is the difference between buying a tool, fixing a process, or commissioning software that matches how the business actually works.
If you are still asking What should I do first when planning a custom software project for my company?, ask those three questions before you ask about features.
Document this before you speak to vendors
Before you talk to any developer, write a one-page problem brief. Not a spec. A brief.
This is the first thing to document because it stops the conversation becoming demo-driven. A vendor can show you almost anything. If you have not defined the problem, you will start judging solutions by polish instead of fit.
Your brief should include:
- the business problem in one sentence
- who feels the pain
- what happens today
- what breaks, slows down, or costs money
- what data is involved
- what systems the new software must touch
- what success looks like in measurable terms
- what is explicitly out of scope for phase one
That last line matters. Scope is not what you dream up. Scope is what you can defend.
A good brief gives you enough structure to compare vendors fairly, estimate effort more realistically, and avoid the classic trap where every demo looks like a possible answer. If the brief is weak, the sales process will fill the gap for you, and usually in the wrong direction.
A practical first pass for Australian businesses
For growing businesses in Australia, the first custom software conversation often starts in one of three places: order handling, reporting, or internal workflow. Wholesale teams want to stop keying repeat orders into emails and spreadsheets. Ops teams want one source of truth instead of five exported CSVs. Leadership wants a system that can scale without adding another coordinator.
That is where tools like B2B Ordering Portals or Data Warehouses & Data Lakes become relevant, but only after the problem is defined properly. A B2B ordering portal makes sense when pricing, terms, and repeat ordering are the pain. A data warehouse makes sense when the business cannot trust its numbers because the source systems do not agree.
The point is not to start with the product category. The point is to identify the bottleneck.
What a good discovery phase actually produces
A proper software discovery phase should leave you with more than a vague “recommendation”. It should produce:
- a clear problem statement
- a mapped current-state workflow
- a list of users and stakeholders
- the key data objects and fields
- integration requirements and constraints
- a first-pass scope for phase one
- known risks and unknowns
- a delivery approach that matches the business
That package is what lets you budget properly and decide whether to build, integrate, or simplify the process first.
If you want a deeper read on the trade-offs before you commit, these help:
- How Do I Choose: In-House, Freelancer, or Agency?
- What Are the Biggest Risks in Custom Software Development?
- How Long Does It Typically Take to Build Custom Software?
The mistake most teams make
They start by asking for features because features feel concrete. They are not concrete. They are the consequence of a decision you have not made yet.
The better question is: what is the smallest clear slice of the problem that, if solved, would remove real friction from the business? That is the first step in custom software project planning. Not the biggest idea. Not the prettiest interface. The smallest useful slice.
That is also why custom software strategy should be tied to business process analysis from day one. If you do not understand the process, you will build around it instead of improving it. And if you do not understand the data, the software will inherit the mess.
For teams in Australia trying to replace manual work without creating another maintenance burden, that distinction saves months.
Use this sequence and you will avoid most rework
If you want the practical order, use this:
- Write the one-page problem brief.
- Run the internal working session with the right people.
- Map the current workflow.
- Identify pain points, data fields, and integration constraints.
- Decide whether the issue is process, data, or software.
- Only then talk to vendors.
That is the cleanest answer to What should I do first when planning a custom software project for my company? and it holds up whether you are replacing spreadsheets, fixing a broken approval chain, or building something your current stack cannot support.
The fastest next move
Take 45 minutes this week and write the one-page problem brief before you book a single demo. If the brief feels fuzzy, that is useful. It tells you where the real uncertainty is.
If the problem is bigger than a quick internal workshop, or you want someone who can challenge the scope before it turns into a costly build, start with Fractional CTO. It gives you the technical direction, vendor accountability, and architectural clarity to turn a messy idea into a buildable plan.
