Skip to the work

Existing software, made fit

The first version was only the starting point.

Some of our best work begins with a module that almost fits. We keep what is useful, rebuild what is getting in the way, and keep refining the system around the people who use it.

See the transformations Bring us the workaround

Recent · Sales and customer experience

A return request became a guided customer workflow.

A return is not one form. It is a handoff from the original sale to the customer, office review, instructions, and warehouse intake.

We shaped those pieces into one return case with eligible quantities, reasons, photo evidence, specific follow-up, visible next actions, and an outcome everyone can follow.

Origin: a custom website and back-office workflow built across Odoo sales, customer, delivery, and inventory foundations.

See the complete customer return workflow

Started with

One return crossing several different roles

The customer, sales, office, and warehouse each needed a different piece of the same case.

What changed

A secure request tied to the original sale
Eligible quantities, reasons, and photo evidence
A visible blocker and next action for the office
Customer instructions and warehouse intake

What became possible

One guided path from the request to the outcome

Each person sees the part they own without rebuilding the order, evidence, decision, or status.

More than new modules

The useful work often happens after “it works.”

These examples began with different foundations. The common thread is patient improvement around real operating conditions.

01 / FINANCE

Statements became a process, not a PDF button.

Review, delivery, payment, policy, history, and recovery all influence the same customer operation.

We refined: Preflight review, direct and scheduled sending, customer-specific policies, delivery monitoring, restart-safe recovery, and online payment paths.
So the team can: Run normal accounts quickly while keeping failed deliveries and unusual account rules visible.

See the complete workflow

02 / OPERATIONS

A product screen became a purchasing cockpit.

Generic product records did not answer the questions buyers and warehouse teams were asking.

We refined: Available-to-sell quantities, kit and component availability, stock locks, vendor context, receipts, forecasts, and purchasing views.
So the team can: Understand what can actually be sold or reordered without reconstructing the answer across several screens.

See the complete workflow

03 / WORKFORCE

A biometric connector became a workforce workflow.

The device connection was only the beginning. Overnight shifts, meal breaks, time off, corrections, privacy, and supervisors still needed a coherent system.

We refined: Shift boundaries, anomaly handling, employee portal access, signed meal records, audit views, access controls, and safe historical rules.
So the team can: Use scanner events as trustworthy attendance work instead of treating the connector as the final product.

See the complete workflow

04 / INBOUND

Containers and landed costs began speaking the same language.

Receipts, backorders, kits, vendor bills, customs calculations, and landed costs all influence the same inbound decision.

We refined: Container progress, grouped transfers, landed-cost preparation, quantity handling, currencies, duties, and kit safeguards.
So the team can: Follow an inbound purchase through the exceptions without losing how the final cost was formed.

See the complete workflow

05 / COMMERCE

Vehicle fitment began behaving like shoppers expect.

A year, make, and model selection is only helpful if it follows the shopper through search, categories, and product decisions.

We refined: Persistent vehicle context, published-product category rules, legacy fitment handling, year restrictions, and stock messaging.
So the team can: Offer a cleaner path from “what fits my vehicle?” to a product that is actually available.

See the complete workflow

06 / INTEGRATIONS

Marketplace and shipping connections became operable.

Moving an order is not enough. People need to know what queued, what shipped, what failed, and whether a retry is safe.

We refined: Amazon and eBay queue behavior, tax and export errors, scoped processing, ShipStation status and tracking updates, schedules, and diagnostic logging.
So the team can: Operate the connections with visible recovery instead of waiting for somebody to notice that data stopped moving.

See the complete workflow

07 / SALES

Sales began seeing the stock it could really promise.

On-hand quantity is not the same as sellable quantity when kits, components, reservations, and stock locks are involved.

We refined: Kit-aware availability, stock-lock effects, sales indicators, performance, freight documents, and customer-specific communication.
So the team can: Make customer commitments with a more honest picture of what inventory can support.

How the work improves

Return to the real day. Then do it again.

The first useful release creates better questions. We use them to improve the next pass instead of pretending the workflow was finished at launch.

01Watch the work
Understand the workaround and the people carrying it.
02Find the friction
Separate the visible complaint from the underlying rule or handoff.
03Shape the workflow
Change the screen, data, automation, or boundary that actually matters.
04Harden exceptions
Plan for bad data, missed steps, permissions, retries, and recovery.
05Return and refine
Use what the operation teaches us to make the next version better.

Use what works. Build what is missing.

A rewrite is not the default. Neither is forcing a bad fit.

EXTEND

When the foundation is sound

Keep the stable module and improve the workflow, interface, rules, integration, or failure handling around it.

BUILD

When adaptation stops making sense

Create the missing operating layer—a focused workflow, portal, kiosk, review queue, or custom application.

A note on origins: some examples on this page began with standard Odoo, community, or commercial modules. We describe Toro’s adaptation, integration, hardening, and custom workflow work without claiming the original foundation as our own.

A good place to begin

Show us the module everyone has learned to work around.

You do not need to know whether it should be extended, rebuilt, or replaced. Start with what people do today and what keeps going wrong.

Tell us the messy version