Owned product history

Building the software was only part of owning the product.

Amidship built a software platform around the day-to-day journey of a service business — from its public website and booking flow through scheduling, clients, payments and administration. By 2017 it was open for public signup and serving paying customers. Years later, production was deliberately shut down; the software itself was preserved and eventually found a narrower second life.

Built · operated · deliberately retired

The problem

A service business is one operation, even when its software is not.

A small service business can easily end up with its website in one place, appointments somewhere else, customer history in another system, payments and invoices in another, and the remaining operating rules scattered across messages, spreadsheets and memory.

The product opportunity was bigger than online booking. The customer journey and the operator workflow were two sides of the same system: discover the business, choose a service, book, pay, return — while the business manages availability, clients, money and the rules around every appointment.

Key decision

Build around the operating journey, not around a collection of disconnected features.

  1. Website / discovery
  2. Service + booking
  3. Client record
  4. Payment / invoice
  5. Business operations
Build around the operating journey, not around a collection of disconnected features.

The product

One system across the customer and operator workflow.

The platform brought together business websites, services, online booking, staff and availability, client records, payments, invoices and sales administration. It also had to deal with the less visible parts of running the business: reminders, cancellation policies, locations, calendars, currencies, time zones and configuration.

That breadth forced the parts to agree with one another. What a customer could book had to match the operator’s calendar. Payment state had to line up with appointments and invoices. Business configuration had to flow through both the public website and the back office.

Inside the product

The 2017 product, as it actually looked.

  1. Public signup · 2017
    Historical Amidship signup screen showing business-account onboarding.

    The onboarding flow for businesses joining the platform.

  2. Business administration · 2017
    Historical Amidship desktop administration showing Bookings, Sales, Clients, Business and Settings navigation.

    Bookings and sales lived alongside clients, business setup and settings.

  3. Mobile scheduling · 2017
    Historical Amidship mobile booking calendar with Bookings, Sales, Clients, Business and Settings navigation.

    The operator workflow extended to mobile rather than stopping at the desktop back office.

Product lifecycle

Knowing when to stop is part of owning software too.

  1. 2015 · Build The horizontal service-business product takes shape.
  2. 2017 · Operate Public signup, paying customers and day-to-day product support.
  3. 2024 · Retire Production is deliberately shut down and recoverable state is preserved.
  4. 2026 · Reuse The same application codebase is reactivated for a narrower vertical under a separate LashDesk brand and legal profile.

On January 1, 2024, the production system was intentionally taken offline. The database and uploaded files were backed up, the production infrastructure was removed, and the old domains were redirected. Keeping an old product alive indefinitely was not treated as the default.

In 2026, the preserved application codebase was reactivated around a much narrower vertical proposition under LashDesk. LashDesk has a separate current brand and legal profile; what matters in this story is the software lineage — a mature system could be reused because the underlying operating model still had value.

Product judgment has to survive the whole lifecycle.

Owning a product means carrying decisions that project delivery often ends before: how much of the workflow to own, what to integrate, how to support real customers, when continued operation no longer makes sense, what should be preserved, and whether existing software deserves another use.

That founder/operator history still shapes Amidship’s work today. We are interested in software that earns the complexity it introduces — and in what happens after the first release, when the product has customers, history, operating costs and consequences.