Issue → RMA → resolution
Order-linked cases, return instructions, exchanges and separate refund records.
Every moving part.
One clear picture.
Your customers, returns, warehouse and stock — connected in one operating platform.
Built around the way your team works. Delivered in stages you can see, test and approve.
Explore the conceptA package’s journey
Label and contents photos stay with the package.
Concept animation · illustrative data12 years building softwareReact + Supabase your requested stackYour code. Your accounts.
01 / Our understandingFour workflows.
Four workflows.
One shared foundation.
Shopify remains the sales system. ShipStation keeps its picking and packing workflows. CTT Ops becomes the place where your team resolves exceptions, receives goods and manages physical stock.
Package → identification
Required photos, internal labels and a review queue for unknown shipments.
PO → receipt → valuation
Partial deliveries, inspection, accepted stock and auditable landed costs.
Reserve → fulfill → reorder
Warehouse or dropship sourcing, bundle components and controlled channel sync.
02 / A first lookLess searching.
Less searching.
More getting things done.
These original concept screens use sample data. They illustrate the proposed workflows and visual direction; they are not a working Shopify or warehouse integration.
Try the navigation, package check-in and partial receipt.Open demo full screen ↗
Interactive sample screens are included in the online proposal. Open mockups.html beside this document to explore the dashboard, returns, package check-in and inventory receiving.
Concept direction: clear hierarchy, generous spacing, consistent rounded surfaces and restrained color, informed by your design reference. The interface here is newly created for this proposal.
Three rules behind these screens
Exceptions have a home.
Unidentified packages, unmatched products and failed syncs stay visible until someone resolves them.
Balances stay separate.
Customer refunds, supplier reimbursements and physical inventory each have their own state and history.
Receiving is deliberate.
A package arriving does not automatically make its contents sellable stock.
03 / Delivery planA useful first release.
A useful first release.
A clear way forward.
Each estimate covers implementation, relevant tests, documentation and a staging demo. These are planning ranges, not a fixed quote for an unreviewed integration. We confirm each milestone's scope and cap before starting it.
Our recommendation
Start with customer operations.
Release A gives your team customer issues, returns, package intake and labels. Then we add stock control, connected channels and replenishment.
$7,680–$12,160192–304 hours · roughly 7–11 working weeks at 30 hours/week
Core platform · M1–M11592–944 hours
Budget range at $40/hour$23,680–$37,760
Release A · start hereEstimate loading
No.Milestone / deliverableHoursEstimate · USDSolo finish window
Timing basis: finish windows are cumulative working weeks from an agreed kickoff at 30 hours/week, not calendar commitments. Client review, API approval and access delays are additional. The 1–3 month job window is best treated as the first release. Extra team capacity can shorten the programme after we agree staffing, responsibilities and a weekly budget; it is not assumed in these dates.
Release E · Optional M12
Automation after the core is stable.
48–96 hours · $1,920–$3,840An initial, explicitly selected automation package: for example Zoho Mail thread ingestion or Discord alerts. Advanced forecasting, seasonality and additional integrations need their own discovery and estimate. This allowance does not cover every potential M12 feature. M10 uses transparent formulas; AI forecasting is not required.
Under the hoodThe technical plan, if you want to go deeper.
React and TypeScript, with Supabase and PostgreSQL. Server-side business rules, private files and a traceable history of important changes.
Application & data
Responsive employee and admin interfaces; Supabase authentication, row-level permissions and private file storage. Shared records link issues, packages, purchase orders, inventory movements and fulfillment. Global search and notifications build on the same access rules.
ReactTypeScriptSupabasePostgreSQL
Integrations & processing
Server-side Shopify, ShipStation and eBay adapters with verified events, background processing, retries and reconciliation. One agreed fulfillment source of truth prevents the same shipment reducing stock twice. Secrets remain server-side.
API adaptersEvent deduplicationRetry queueSync audit
One physical item,
many sales listings.
Master inventory owns physical stock. Shopify variants, supplier SKUs, aliases and kit components map to it. Unmapped listings are held for review before stock is published.
Stock moves once.
Use transactional inventory movements, stable event identifiers and reconciliation. Warehouse reservations release on source changes; dropship items do not deduct warehouse stock.
Costs can arrive late.
Mark estimates and provisional costs explicitly. Apply quantity-based freight allocation by default, preserve original movements, and record later cost corrections with an audit trail. Agree the treatment of already-sold units before implementation.
Hardware is tested early.
Validate a 4×6 print on your LP320 and Mac in M4. Start with a browser/PDF print workflow; unattended printing or a custom driver bridge would be a separate scope if the warehouse requires it.
05 / Our working processYou see the work.
You see the work.
Every step of the way.
You work directly with Rashin. Development and QA support are agreed around each release. We use Claude Code and Codex to help with implementation, debugging and tests, while reviewing the code and checking real workflows.
Define the result.
Review real examples, data and permissions. Agree the milestone scope, acceptance checks, estimate and spend cap.
Keep it reviewable.
Work in small branches and pull requests. Share progress and decisions, with an early staging walkthrough.
Test what can break.
Check permissions, retries, duplicates, partial receipts, source changes and cost corrections—not only the happy path.
Release with evidence.
Demo the agreed scenarios, record limitations, provide handover notes and obtain acceptance before the next scope.
What you receive with every milestone
- Working staging demonstration
- Source committed to your GitHub repository
- Database migrations and configuration notes
- Relevant automated and workflow test results
- Known limitations and incomplete items
- Deployment and rollback instructions
- Acceptance checklist with results
- Short walkthrough and next-step notes
06 / Relevant workWe’ve built the
We’ve built the
work behind the screen.
These projects show our experience with operational workflows, permissions, payments and traceable data. The CTT Ops warehouse and channel integrations would be built specifically for your business.
BookingOps
Customers, quotes, scheduling, jobs, invoices and payments in one platform, built with Next.js, TypeScript and PostgreSQL.
Relevant here: connected records, role-based workflows, payment handling and business operations. Rashin's work includes checkout shared by the website and voice agent, with tests around payment branches and customer context.
View BookingOps ↗Watch the application walkthrough ↗
Aquila Insights
Our team's laboratory operations portal connects submissions, sample records, CSV imports, review and approval workflows, and reporting.
Relevant here: data validation, exceptions requiring review, organization-level access and reports tied to the underlying records. Rashin's contribution includes workflow definition, acceptance criteria and delivery handoff.
A walkthrough can be discussed through Upwork, subject to client permission.12 years of software experience.
A team behind the delivery.
Rashin leads the engagement and technical decisions, with up to 30 hours/week of personal availability. Additional developers and QA are scheduled by agreement and included in the approved work budget. We do not assume an unlimited team or silently add parallel billable hours.
07 / Commercial proposalStart small.
Start small.
Stay in control.
The listing is hourly. The default proposal is $40/hour, organized into separately approved milestones. No commitment to all 12 milestones is needed to begin.
Recommended: capped hourly stages
- Agree the hours range and a written spend cap for each milestone before work starts. Hours are billed through Upwork under the agreed hourly contract.
- Share hours used, work completed and remaining forecast each week. Pause for written approval before exceeding a milestone cap or adding scope.
- Demo and acceptance gate the next milestone. Hourly billing follows Upwork's contract cycle; it is not held in escrow until acceptance.
- The published estimates use $40 per total delivery hour. Any additional team rates or hours must be agreed in advance; no unapproved parallel billing.
If you prefer fixed-price payments
- After discovery, agree a fixed deliverable, acceptance criteria, deadline and price for each milestone in an Upwork fixed-price contract.
- Fund each agreed milestone before its work starts. Submit the staging demo, source, migrations, tests and handover as the completion package.
- Request payment release through Upwork after acceptance, subject to its milestone review process. Do not fund the whole programme upfront.
- Changes outside agreed acceptance criteria receive a separate estimate. Include 14 calendar days of correction support for reproducible defects in accepted deliverables; new features and third-party changes are separate.
Estimate assumptions & scope boundaries
- One internal operating business and one initial warehouse. Multiple Shopify stores are supported; store count and account access are confirmed in M1. A resale SaaS with tenant billing is not assumed.
- The first integration pass uses two Shopify stores as a planning allowance, one ShipStation account and one eBay account. Larger account counts, complex historical data cleanup or additional sales channels require review.
- Customer refunds are tracked separately from supplier reimbursements. Any API action that issues money needs explicit authorization and role controls; its exact execution scope is confirmed in M3.
- M4 includes supplier/company label attachments and a 4×6 internal package label. Buying carrier postage or building a shipping-rate engine is not assumed.
- Supplier contact methods are stored as references. WeChat/WhatsApp messaging integrations, email-thread ingestion and automated supplier orders belong to separately scoped automation.
- Hosting, API subscriptions, email, storage, printer/scanner hardware and payment-provider fees are paid through your accounts and excluded from development estimates.
- Accounting rules, valuation corrections, negative-stock policy, kit mappings and source-of-truth decisions are agreed using examples before implementation.
- Client access, representative data, sandbox accounts, hardware testing and prompt review are dependencies. Timelines begin after the agreed inputs are available.
- Security work includes role tests, private storage and integration secret handling. Formal certification or a third-party penetration test is a separate engagement.
- Build and production data remain in your repository and service accounts. These concept screens use fictional data and do not connect to your stores.