This is not a side app. It is core operating infrastructure.
Morrison's pricing tool sits at the point where sales, production, freight, margin, and customer response time meet. A faster prototype is useful. A modern application that the team can trust is the bigger step.
The right first project is narrow enough to ship quickly and meaningful enough to prove how Benali works. The pricing tool is already the work Morrison is trying to fix. It is concrete, high-volume, and tied directly to quote flow.
We would treat this as a real application build, not a prompt, shortcut, or experiment. The goal is a tool Morrison can put in front of users quickly.
A clean quoting surface with the pricing logic underneath it.
The exact stack and implementation details are confirmed in a technical scope and design session. The target is a modern tool that can replace the current workflow, connect to approved systems, and give Morrison confidence that the quote logic is controlled.
Quote workflow
Intake, calculation, review, and output surfaces built around the way Morrison's team actually prepares quotes.
Pricing modules
The current module logic is mapped, standardized, tested, and made easier to maintain than a fragile prototype.
Data and APIs
Approved data sources and external APIs are connected deliberately, with errors surfaced instead of hidden.
Admin rules
The rules that need business review are separated from the parts that should never drift casually.
Real quote testing
We test against sample quotes, edge cases, freight scenarios, and known exceptions before rollout.
Maintenance path
After launch, Managed AI Ops keeps the system current as APIs, pricing rules, and workflows change.
It means the less glamorous parts are handled: clear architecture, reliable calculations, permission boundaries, visible error states, real quote testing, maintainable rules, and a path for changes after launch.
Custom software needs product judgment, not just code.
This build is not only about recreating screens. It needs the judgment to decide what should be simple, what should be configurable, where errors should surface, and how the tool should feel when Morrison is quoting real work under time pressure.
Application judgment
Years of experience building software in demanding product environments shapes how we scope, sequence, and simplify the tool before it becomes code.
Useful by default
The quoting flow should be clear, fast, and hard to misuse. Good internal software reduces effort instead of adding another system to babysit.
Built for real use
Performance, reliability, maintainability, integrations, and edge cases are part of the build from the start, not cleanup work after the demo.
Speed without sloppiness
AI helps us move faster, but the quality bar still comes from human product taste, engineering review, test discipline, and careful rollout.
Map the logic, build the system, test it against real work.
The sequence starts with a required technical scope and design session. We need to understand the full application, walk through the high-level design, and make the quoting work legible before the build begins.
- Technical scope and design session. Walk through modules, users, current screens, quote flow, data sources, API access, edge cases, and the high-level application design.
- Workflow and logic map. Document how a quote moves from request to final number, including opportunity-cost rules and freight inputs.
- Application build. Build the quoting surface, integrations, and admin controls in a stack chosen for maintainability and AI-assisted iteration.
- Test and harden. Run real examples, edge cases, error states, permissions, and handoff paths until the team can trust the result.
- Launch and maintain. Roll out to the right users, document the system, and keep Benali accountable for improvements and fixes.
A build range that becomes fixed after technical scoping.
The technical scope and design session is required before we lock the final number. The unknowns are not whether this is worth doing; they are the application shape, API details, data quality, module complexity, and the design decisions needed to make the tool usable.
Expected build range for the pricing-tool rebuild, finalized after the required technical scope and design session. Timeline target: 2-6 weeks after scope is confirmed.
Recommended support
Managed AI Ops, likely the Managed tier at $5-8K per month, keeps the pricing tool owned after launch. That includes workflow tuning, permission review, small improvements, adoption support, and ongoing system care.
Fast work still needs the right access.
This project moves quickly if the business inputs are available early and the decision path is clear.
Decision owner
Ryan and Val available for scope choices, tradeoffs, and launch decisions.
Real examples
Representative quotes, edge cases, exception rules, and any known pain points.
System access
Approved access to the data, APIs, and current tool needed to rebuild accurately.
Internal expert
A Morrison subject-matter expert available to clarify how the business thinks about the work.
Next step: technical scope and design.
If the pricing tool is the right first project, the next step is a focused working session to walk through the app, confirm the modules and data sources, review API access, sketch the high-level design, and define the launch path. After that, we can finalize the number and start the build.