Software
Ecommerce app development
Most ecommerce projects do not need a custom platform. They need a custom slice on top of one. Here is where the line sits and what actually decides whether the build pays for itself.
By Umar HayatChief Technology Officer, Algo Vortex
Key takeaways
Do not rebuild checkout
Payments, tax, and fraud are solved by vendors who do nothing else. Custom checkout is the most common expensive mistake.
Build where the model is unusual
Rentals, made-to-order, subscriptions with odd rules, marketplaces. That is where platform limits become real costs.
Catalogue complexity is the tell
If variants, availability, or pricing cannot be expressed in the platform's model, you have found the reason to build.
Mobile app only after web works
A native app is a retention play, not an acquisition one. Build it when you have repeat customers to retain.
Should you build, extend, or buy?
Buy the platform if your business is close to standard retail. Products, variants, cart, checkout, shipping, returns. Shopify and its equivalents have solved this and they have solved it better than a custom build will, because they have run it across millions of stores and encountered every edge case you have not yet imagined.
Extend the platform if most of it fits but one part does not. This is where the majority of real ecommerce engineering happens, and it is usually the correct answer. A custom storefront on a commerce API, a custom pricing engine, a customer portal, or a bespoke fulfilment integration, all sitting on top of a platform that keeps handling checkout and payments.
Build custom when the commerce model itself is the problem. Rentals with date-based availability. Made-to-order with configuration that affects price and lead time. Marketplaces with multi-party payouts. Subscriptions with usage-based or contractual pricing. In each case the platform's data model is the constraint, and fighting it costs more each year than replacing it once.
Loom & Luxe is our work in the third category: a dress rental platform where availability is date-based and a garment can only be in one place at a time, which is not a model standard retail platforms hold well.
Where each option fits
Situation
Standard retail catalogue
Approach
Buy platform
Why
Solved better than you will solve it
Situation
Standard catalogue, custom experience
Approach
Headless on platform API
Why
Keep checkout, own the front end
Situation
One workflow does not fit
Approach
Extend with a custom service
Why
Cheapest real fix
Situation
Rental, made-to-order, marketplace
Approach
Build custom
Why
The data model is the constraint
Situation
Multi-party payouts
Approach
Build with a payments provider
Why
Platform payout models rarely fit
| Situation | Approach | Why |
|---|---|---|
| Standard retail catalogue | Buy platform | Solved better than you will solve it |
| Standard catalogue, custom experience | Headless on platform API | Keep checkout, own the front end |
| One workflow does not fit | Extend with a custom service | Cheapest real fix |
| Rental, made-to-order, marketplace | Build custom | The data model is the constraint |
| Multi-party payouts | Build with a payments provider | Platform payout models rarely fit |
Why should you not build your own checkout?
Because checkout is where the hard regulated problems live and none of them are your competitive advantage. Card data handling and PCI scope. Strong customer authentication in Europe. Sales tax and VAT calculation across jurisdictions that change rules on their own schedule. Fraud scoring. Chargeback handling. Payment method coverage, which varies by country in ways that materially affect conversion.
A payments provider does all of this as their entire business. Using their hosted or embedded checkout keeps card data out of your systems, which reduces your compliance scope from a project to a questionnaire. Building it yourself means taking on all of that and getting a slightly more consistent visual design in exchange.
What is worth customising is everything around checkout. The cart, the shipping selection, the upsell logic, the address validation, the confirmation experience. Those affect conversion and they are safe to own. The payment step itself should be handed to someone whose insurance covers it.
The one legitimate exception is genuinely unusual money movement, like splitting a payment across multiple sellers or holding funds until a rental returns. Even then you build on the provider's primitives rather than replacing them.
How do you know the catalogue model is the problem?
Look at how you are currently representing the thing you sell. If a product has been split into forty variants to express two dimensions of choice, the model is fighting you. If availability depends on dates rather than a stock count, standard inventory does not describe it. If price depends on a configuration the customer builds, a price field does not hold it.
Rental is the clearest case. A garment is available on specific dates, in transit on others, and being cleaned on others still. That is a calendar per unit, not a quantity, and it needs booking logic with overlapping reservations, buffer periods, and a concept of a physical item that a stock count cannot express.
Made-to-order is the second. Lead time and price both depend on what the customer selected, and the selection has interdependencies where one choice makes another unavailable. That is a configuration engine, and platforms model it as option lists that do not know about each other.
Digital and licensed goods are a third, quieter case. Entitlements, seat counts, and renewals behave more like SaaS than retail, and if you are selling those alongside physical goods you are running two different models in one catalogue.
What actually affects conversion?
Speed on the pages that matter, which are the product page and the cart. These need to be fast on a mid-range phone on a mobile network, not on a developer's laptop. Server-render the product page, keep images properly sized and in modern formats, and be strict about third-party scripts, because analytics and marketing tags are the most common reason a fast site becomes a slow one after launch.
Search and filtering on any catalogue past a few hundred items. Customers who cannot find a product do not browse patiently, they leave. This is worth real engineering attention and it is frequently underinvested because it is less visible than the homepage.
Trust signals at the decision point. Stock accuracy, honest delivery estimates, a visible returns policy, and a checkout that does not surprise anyone with a shipping cost at the last step. Surprise costs at the final step are among the most reliable ways to lose a completed cart.
And mobile as the default rather than the adaptation. Most traffic is mobile for most retailers, so the phone layout is the real design and the desktop one is the variation.
When is a native mobile app worth building?
When you have repeat customers. A native app is a retention mechanism, not an acquisition one. Nobody discovers a store by installing its app, so the app only pays for itself if there is a base of returning buyers to make more loyal. If your purchase frequency is annual, a good mobile web experience is the better investment.
The things an app genuinely does better are push notifications, saved payment for one-tap reorder, and loyalty programmes that feel present rather than remembered. If none of those change behaviour for your customers, the app is a second codebase to maintain for a marginal gain.
When you do build one, share what can be shared. A cross-platform framework over one commerce API keeps you from maintaining three implementations of the same business logic. Web and mobile development is the commercial path.
Budget for the ongoing cost honestly. App store review cycles, two platforms of operating system updates, and users on old versions you still have to support. An app is a permanent commitment, not a project.
How should the build be sequenced?
Get one product category selling end to end before widening. Real payments, real fulfilment, real returns, on a narrow catalogue. That surfaces the integration problems while they are still cheap to fix and gives you revenue while the rest is built.
Then fix what the data shows rather than what the roadmap assumed. Analytics on the funnel will tell you whether the problem is discovery, the product page, or checkout, and it is frequently not the part the team expected. Building the next planned feature instead of the one the data points at is how ecommerce projects run long without improving.
Then the operational tooling. Order management, returns processing, and customer service views are unglamorous and they determine whether the business can actually run at volume. This work is consistently deferred and consistently becomes urgent.
How to build custom software covers the slice approach, and custom software vs off-the-shelf covers the wider buy-versus-build frame.
Next step
Platform fighting how you actually sell?
Send the catalogue shape, the checkout you use today, and the workflow that does not fit. We will say extend, build, or stay, and what a first slice looks like.
Talk to Algo VortexRelated in this cluster
- Custom software vs off-the-shelfBuy when a vendor already models your work. Build when the workaround tax is the product. Hybrid is common: vendor for the generic slice, custom for the edge that makes you money.
- How to build custom softwareStart with the job, the users, and a first slice you can demo. Then data model, integrations, and a release in an environment you control. A platform for every department is how first builds die in committee.
- Custom software development costCustom software in 2026 lands in bands, not a single quote. The build, hosting, and the people who keep it all show up. Here is how those numbers typically break for a first production version.
- API integration servicesIntegrations are where estimates go wrong, because the demo works on the first call and the project lives in the failure cases. Here is what the work actually contains and how to scope it honestly.
Related capabilities
Related case studies
Live products where this kind of work showed up in the build.
Loom & Luxe: rent the dress, skip the full retail bill
Rentals, deposits, and return logistics
Loom & Luxe makes designer dresses reachable for short events. Shoppers browse an editorial catalog, book a rental window, pay a fraction of retail, and get pickup handled when the window closes. Owners and brands need inventory, active rentals, and earnings in one lender dashboard instead of side chats and spreadsheets. The business needed rental commerce that feels like shopping, not a form dump. Deposits, delivery addresses, and returns had to be productized. If those steps stay manual, the marketplace cannot grow past a handful of garments and a very patient ops person. Trust sits at the center. Renters need deposits and holds that feel fair. Lenders need payouts and inventory status they can verify. Both sides had to feel comfortable putting real garments and real event dates into the system, not treating it like a weekend experiment. The storefront had to feel like fashion retail while the backend behaved like a logistics system. Pretty pages without return automation fail. Automation without an editorial catalog fails too. That tension is the real product.
Gusto: find food through friends, not empty star dumps
Maps, feed, and restaurant profiles
Gusto helps people find places worth eating through maps, friends, and dish photos, without another generic ratings wall. Star averages hide whether a place fits your crowd. Discovery should be shaped by taste and people you follow, with a map you can browse and photos that show the plate. That means a social loop that still feels fast on mobile: posts, reviews, notifications, and profiles that stay useful when you are already standing on a sidewalk deciding where to walk next. Web sits alongside for browsing, but the core experience is built for phones in the wild. Hospitality discovery fails when every place looks the same on a star list. Gusto bets on social proof you can inspect: who posted, what the plate looked like, and where it sits on the map. The product should feel useful while you are already outside, not only when you are planning from a desk. Friends and photos are the ranking signal the product wants to earn. Maps provide place and distance. Together they answer "where should we eat" with more than a cold average score.
Questions
More on all insights, custom software, or contact Algo Vortex.