Every software vendor sounds similar in the first meeting: experienced team, modern stack, happy clients. The differences that will actually shape your project live one layer deeper — and they surface fast if you ask the right questions. Here are the seven we’d want answered if we were the ones buying, and what a good answer sounds like.

1. “How do you arrive at a price?”

Good answer: a structured discovery process with deliverables — requirements, wireframes, a ranked feature list — and a price built on them. Warning sign: a confident number in the first hour. An estimate without discovery is a guess with a signature, and someone will pay for the gap later.

2. “When do I first touch working software?”

The answer should be a number of weeks, followed by “and every few weeks after that.” Screenshots and status decks are not software. If the first hands-on moment is launch day, all the risk has been saved up for the most expensive possible moment.

3. “What do you test against, and who tests?”

Listen for two things: test cases written from the agreed requirement (not improvised at the end), and your team included as reviewers each release. Quality that isn’t a process is a hope.

4. “Who owns the code?”

The only acceptable answer is you. Ask specifically: if we part ways, can another team pick this up — repository, documentation, credentials and all? Vendors confident in their work don’t need lock-in to keep clients.

5. “What does year two cost?”

Hosting, patches, API changes, small improvements — a real vendor quotes the ongoing picture with the build. Silence about year two is how “affordable” projects become expensive ones. (Our accountant wrote a whole maintenance budget guide.)

6. “Tell me about a project that went sideways.”

Everyone has one. What you’re evaluating is the honesty of the telling and what changed afterward. A vendor with no such story is either brand new or not being straight with you — both are answers.

7. “Will you tell me if I shouldn’t build this?”

Sometimes the right answer is off-the-shelf software, an integration, or nothing at all. Ask for an example of a time they talked a client out of a project. The vendors who can answer are the ones whose recommendations you can trust when they say build.

We’ve written before about why we won’t quote a project on the first call — discovery is where the real number comes from. But discovery is a two-way exercise: the quality of the blueprint depends on what you bring into the room. Here’s how the clients who get the most out of it prepare, in about two hours of homework.

Bring the people who do the work

The single biggest predictor of a good discovery is who’s in the room. Owners know the strategy; the person who processes orders every day knows the seventeen exceptions the strategy doesn’t cover. When we built a warehouse system, the floor team’s answers shaped the design more than the org chart did. Invite the doers, and tell them honestly that the goal is to remove the annoying parts of their job — not their job.

Collect the artifacts, not just opinions

Before the workshop, gather the things your process actually runs on: the spreadsheet everyone updates, a sample invoice, the email template you send customers, screenshots of the systems you use, last month’s “weekly report” someone assembles by hand. Real artifacts beat descriptions every time — they show us the data you track, the steps nobody mentions, and the workarounds that have become invisible to you.

Write down the top three pains, ranked

Not features — pains. “We can’t tell customers where their order is.” “Quoting takes two days.” “Month-end reporting eats a week.” Discovery will translate pains into features and rank them by value; your job is to be honest about which problem, if it vanished tomorrow, would matter most. Disagreement inside your team about that ranking is not a problem — surfacing it in the workshop is precisely the point.

Decide what “working” would look like

Come with a number attached to the pain wherever you can: hours per week re-typing, calls per day about order status, orders lost to slow quotes. Those numbers become the yardstick the finished software is measured against — and they’re how you’ll know, a year later, whether the project paid for itself.

What you’ll walk away with

From our side: a requirement document in plain language, wireframes of every screen, a feature set ranked by business value, and a price built on all three. It’s yours to keep whatever you decide — which is exactly why we want you to come prepared. A blueprint is only as good as the building it describes.

“Customer portal” sounds like software jargon until you translate it: a place where your customers serve themselves. They log in, see their orders, download their invoices, reorder what they bought last month, and check delivery status — without calling anyone at your company. I build these for a living, and the pattern after launch is always the same: the phones get quieter and the orders get bigger.

The call that never happens

Count how many calls your team answers that boil down to “where’s my order?”, “can you resend that invoice?”, or “what did we buy last time?” Each one interrupts a salesperson or ties up the front desk, and each answer already exists in your systems — the caller just can’t see it. A portal makes it visible. For the parts distributor we work with, the ordering portal shows live inventory and order status pulled straight from the warehouse system, so the status a customer sees is actually true. Those calls didn’t get faster; they disappeared.

Self-service customers order more, not less

Owners sometimes worry that removing the human touch will shrink orders. The opposite happens. A customer who can browse your full catalog at 9 p.m., see what’s in stock, and reorder in three clicks isn’t limited to what they remembered to ask about on the phone. Reorders become routine instead of errands. And your salespeople — freed from reciting order statuses — spend their calls on the conversations that actually grow accounts.

What separates a portal from a login page

The portals that get used share one trait: they’re wired to the systems that run the business. Live inventory, real order status, actual account pricing, invoice history from your accounting system. A portal that shows stale or generic data trains customers to call anyway — which is why portal projects are really integration projects, and why we scope the data connections before we design a single screen.

Where to start

You don’t need every feature on day one. Most successful portals launch with the two or three things customers ask about most — usually order status, order history, and reorder — then grow release by release from what logged-in customers actually do. If your team spends hours a week being a human status page, that’s the signal it’s time.

Astotek started by building websites, so we say this with love: at some point, a website stops being the solution and starts being the symptom. The business grows, the site stays a brochure, and the gap between them fills up with phone calls, spreadsheets and workarounds. Here are the five signs we see most often — and what usually comes next.

1. Customers call to do things the site should do

Order status, reorders, appointment changes, account balances — if your phone rings for tasks a logged-in customer could do themselves, you’ve outgrown the brochure. A customer portal turns your busiest interruptions into self-service, around the clock.

2. The contact form is your entire pipeline

Every inquiry arrives the same shapeless way, and someone re-types it into wherever it actually lives. When the form feeds a real workflow — quoting, scheduling, follow-up — leads stop leaking between the inbox and the system.

3. The website and your operations don’t know each other

The site says “in stock”; the warehouse disagrees. Prices on the site lag the price list. When the website is wired to live inventory and real data — like the ordering portal we built for a parts distributor — it stops being marketing and starts being infrastructure.

4. Staff have browser tabs for everything

If running the business means six logins and a spreadsheet to bridge them, the next “website project” is really an internal application wearing a website’s clothes. That’s a good thing — it’s where the ROI lives.

5. You’ve started saying “the system won’t let us”

Off-the-shelf tools shaped your process to fit them. When you catch your team designing work around software limitations instead of customers, it’s time for software designed around the work.

What comes next

The path we’ve walked with many clients: website, then the application behind it, then the platform that runs the operation. It starts with discovery — mapping what the business needs the site to become before anyone writes code.