Creative by nature.

Building beautiful, intuitive systems.

I’m Tyler. I design and build apps, websites, and the systems behind them—including The Laundry Concierge and You In?, a social-planning app in closed beta.

Explore the work ↓
SELECTED WORK
01 · The Laundry Concierge02 · You In?
01 / BUSINESS & PRODUCT ECOSYSTEMCustomer & provider apps on iOS + Android
TLC washer mark

The LaundryConcierge Co.

From the first pickup
to the final payout.

Customer, provider, and operations apps for a pickup-and-delivery laundry business.

MY CONTRIBUTION

Founder · Product design · App & website development · Backend integrations · Release work

The apps

Customer · Provider · Operations
FOR OPERATIONS

TLC Grow

Oversee orders, providers, finances, and customer support.

Real iOS screens · illustrative account and order dataTap any screen to explore ↗

The order. The conversation.

Progress tracking, care instructions & direct chat

Progress, care instructions, and a direct line to the person handling your laundry.

Real app screens · sample order and messages
Order details
Order chat

Website & in-app support

The public front door and Ask TLC
THE PUBLIC FRONT DOOR

The TLC website

↗

From service discovery to scheduling and support.

SUPPORT IN THE APPS

Ask TLC

In-app guidance and current pricing, with human help a tap away.

See its boundaries ↗

The service continues in the inbox.

Welcome emails & custom job invoices

The systems behind the screens.

Shared records, Stripe, access rules & AI boundaries
01 / Connected products

Three apps. One service to run.

Three role-specific apps share the records behind each order. I connected the customer journey, provider workflow, and operations tools.

TLC Co.Book & track
TLC ProsFulfill & deliver
TLC GrowOversee & resolve
SHARED SERVICE RECORDS · SUPABASEOne order, carried through the service.
Scheduled→In progress→Delivered

Care instructions · order status · conversation · saved pricing

Shared information. Different workflows and permissions.

Details & verification

Customers, providers, and administrators need different tools, but they’re working on the same service. I connected the booking, fulfillment, conversation, pricing, and operations workflows around shared records.

Conceptual architecture based on the TLC apps and shared Supabase order/pricing workflows. The website adds discovery, signup, scheduling, and support. This diagram simplifies the system; it is not a claim that every client receives every update instantly.

02 / Stripe integration

Money needs more than a Pay button.

Saved amounts, permission checks, and recovery for uncertain responses. I built the safeguards around Stripe payments and provider payouts.

CUSTOMER PAYMENT
Saved order priceReload the stored amount
→
AuthorizeKeep valid same-total holds
→
CaptureEnforce order & payment rules
GROW · PROVIDER BANK PAYOUT
ReviewCheck amount & destination
→
Confirm onceStable idempotency key
→
ReconcileTrack the operation result

Unknown outcome? Check the recorded result before trying again.

Provider transfers and bank payouts are tracked as separate stages.

Details & verification

I built the checks around payment and payout actions: saved amounts, current permissions, valid financial states, and recovery when a response is uncertain. A retry should start by finding out what already happened.

The September payment work recorded 32 mocked handler tests covering permission, stale writes, failed saves, authorization/capture errors, and retries. October Grow finance work recorded 18 backend tests for server-owned reviews, expiry, duplicate confirmation, destination changes, and unknown outcomes. Backend deployment is documented; these checks did not send a real instant payout or charge a live card.

03 / Access & privacy

The right person. The right order.

Order history and proof photos are restricted to the customer, eligible assigned Pro, or an administrator. The server enforces the rule.

Permission is checked for the record.ON THE SERVER
Recorded permissions for order history and proof photos
Who’s asking?Order historyProof photos
Order’s customer✓ Allowed✓ Allowed
Assigned Pro✓ Allowed✓ Allowed
Administrator✓ Allowed✓ Allowed
Unrelated / signed out— Denied— Denied

Grow’s finance actions also require a current admin check. Stripe secrets stay on the server.

Details & verification

A hidden button is not an access rule. For order history and proof photos, I restricted access to the order’s customer, eligible assigned provider, or an administrator—and checked unrelated and signed-out cases.

October 8 deployed database checks verified participant/admin reads and unrelated/signed-out denial for the scoped history endpoint and proof-photo policies. All existing proof objects and status events were retained. Actual signed-JWT file transfer was a separate acceptance step. These are specific implemented controls, not a whole-system security certification.

04 / Shared pricing

Change the catalog. Keep the agreement.

Current rates flow from Stripe to the apps and website. Accepted orders keep their saved prices.

StripeCurrent default prices
→
Validate & publishService-only, single-use claim
New ordersUse the current catalog
Accepted ordersKeep their saved prices
44

existing orders checked.
No prior item prices or totals changed.

Details & verification

I connected Stripe’s current prices to the shared catalog used by the apps and website. New orders use updated rates; accepted orders keep their saved prices. Invalid catalog changes stop before publication.

October 15–16 records cover service-only publication, single-use claims, duplicate/invalid price rejection, atomic updates, and configuration conflicts. All 44 existing orders retained prior item prices and totals; six unfinished orders gained only missing optional items. A new optional item does not itself charge a customer.

05 / Ask TLC

Useful answers, with a defined boundary.

Approved guidance, current pricing, and limited profile context. When a question falls outside those boundaries, Ask TLC points to the app or human help.

Approved guidanceCurrent pricingOwn-profile facts
Consumer Ask TLCResolve only caller-authorized, read-only context
Within scope

Answer from available facts.

Outside scope

Open the app or contact support.

Detailed orders, jobs and payments are excluded from consumer account context.
Details & verification

I connected the assistant to approved guidance and current pricing, with narrowly scoped profile context. If facts are unavailable or the request needs detailed account access, it gives an honest fallback or a path to human help.

Consumer Ask TLC launch scope is guidance plus the caller’s own permitted profile facts. Detailed orders, jobs, and payments are excluded; Grow’s admin assistant has a separate scope. October launch/pricing regressions cover authorization and unavailable pricing. Signed-in end-to-end acceptance is distinct from backend tests.

06 / History & notifications

Keep the conversation in sync with the work.

Recorded order events appear beside messages without creating fake chat. Push alerts have their own routing and delivery checks.

Order status changes

Keep the recorded timestamp.

History appears in the conversation

Read existing events; don’t insert fake chat messages.

Notify through the right channel

Route iOS devices and share a signed push credential within a batch.

Push gateway acceptance is recorded separately from receipt on a phone.

Details & verification

Order activity belongs beside customer and provider messages. I projected recorded status events into the conversation without inflating unread counts, and separately improved iOS push routing and credential reuse.

The October status reader preserves recorded timestamps, checks order membership, supports paging, inserts no chat records, and sends no extra push. The September iOS notification repair reused APNs credentials within a worker and shared concurrent refreshes. A targeted sandbox push was accepted by Apple; actual phone receipt remained a separate check.

TOOLS IN THE BUILD

SwiftUI · Kotlin · Next.js · Supabase · Stripe · Cloudflare · Resend

Customer experience → provider workflow → operations
02 / SOCIAL PLANNING Closed beta

You In?

Less back-and-forth.
More getting together.

Find when friends are free, make a plan, and work out the details together.

MY CONTRIBUTION

Product design · Flutter / Dart · Supabase data & permissions · Beta testing

Find the time. See the possibility.

Shared availability & opportunity cards

A shared view of everyone’s week, with opportunity cards that turn overlapping free time into a reason to get together.

How it works
DESKTOP · The week at a glance
MOBILE · Openings worth a plan
Your week, your way

One-off time blocks and recurring availability.

The right people

Compare friends and selected Circles.

A next step

Turn an available window into a plan.

Real app UI and profile photos. Availability and opportunities are illustrative.

One plan. Everyone on the same page.

Plan details, invitations & RSVPs

Your people, beyond a single plan.

Circles, member statuses & shared conversations

A familiar group for more than one event. Circles bring member statuses, a shared conversation, and the next plan into one place.

How it works
DESKTOP · Members, availability & what’s next
MOBILE · The group at a glance
Stay connected

A persistent group and shared thread.

See who’s around

Member statuses beside real profile photos.

Make the next plan

Move from the group into planning.

Current Flutter screens with illustrative Circle statuses and plans.

The conversation can do more.

Rides, shared expenses, polls & lists

The systems behind the screens.

Six engineering stories, with diagrams & optional detail
Availability→Opportunity→Plan→Discussion & toolsFriends & Circles connect the people. Permissions govern the access.
01 / HOW YOU IN? WORKS

Find the overlap. Make the plan.

Shared availability becomes opportunity cards showing who could meet, and when.

A closer look

I built the Board around weekly rules, date-specific time blocks, and plan windows. The overlap calculation compares time-zone-aware intervals and distinguishes clear opportunities from less certain ones. Only accessible, selected friends’ Boards enter the comparison; an opportunity is a suggestion, not a booking.

02 / HOW YOU IN? WORKS

A group worth keeping together.

Circles give a recurring group its own members, shared plans, and conversation.

InviteAn organizer invites someone
→
AcceptThey choose to join
→
Keep in touchPlans + a Circle thread
Weekend crew
AJSYou

One familiar group for the next plan.

A closer look

Members can request an invitation for an eligible friend; the organizer reviews it. Server-side checks verify current membership, ownership, friendship, and blocks before accepting the action. Circle-based availability sharing is a separate permission, not automatic access to someone’s whole Board.

03 / HOW YOU IN? WORKS

Two people shouldn’t claim the last seat.

Ride cards connect a friendly interface to participant checks and capacity rules.

01Request a seatPending requests reserve nothing
02Check & acceptMembership + remaining capacity
03Confirm the rideAccepted seats count toward capacity
3 seats offered

2 accepted · 1 available

Illustrative ride offer. The server serializes acceptance on the ride record.

A closer look

These are structured records attached to the discussion, so a ride request or expense stays actionable after newer messages arrive. Ride acceptance checks available seats and plan membership. Expense cards track who owes and who has paid; they do not move money. Tasks, lists, and coordination items can be completed and reopened.

04 / HOW YOU IN? WORKS

Sharing has a boundary.

Current status and full-Board access are separate choices, with controls for people and Circles.

CURRENT STATUS“Available tonight”A present-tense signal
FULL BOARDYour wider scheduleA separate sharing choice
Person / Circle access→Server checks the viewer

Blocks and “Hide all” take priority.
Joining a group doesn’t bypass those choices.

A closer look

I separated the social signal from access to the full schedule. The source includes row-level security, recipient-specific availability resolution, Circle grants, exclusions, blocks, and a “preview as this person” view. Related SQL and widget tests cover those boundaries.

05 / THE EXPERIENCE BETWEEN SCREENS

Fast feedback.
A path back when things fail.

A message appears immediately, then reconciles with the server’s saved version.

01Show it nowOptimistic local message
02Save it onceOperation ID + server record
03Keep it in syncRealtime changes reconcile
If the send fails

Remove the pending bubble and restore the text for another try.

What I built

Plan discussion sends use a client operation ID to reconcile the optimistic bubble with the saved record. A failed send restores the draft and reply context. Realtime listeners refresh messages, reactions, polls, coordination items, and logistics; older message pages are merged without adding records already present.

Direct and Circle chats also retain the operation ID for retrying the same failed send. Plan messages also have a database uniqueness constraint on sender and operation ID.

06 / SMALL DETAILS, REAL ENGINEERING

A new crop shouldn’t cost you the original.

Plan covers retain their source photo separately from the display crop.

Original photoRetained for re-cropping
Display cropFramed for the plan
Save both—or clean up

Staged uploads are removed if saving fails.

Private storage, permissioned reads.
Cover access is limited to the owner and plan participants.

What I built

The editor keeps the original source bytes and the display crop separately, so opening the crop editor again does not repeatedly crop an already cropped image. Saving handles upload cleanup on failure. The plan-covers bucket is private, with owner-scoped upload rules and participant-aware reads.

These describe the implementation. Storage rules and device behavior have their own acceptance checks.

Mobile & web · Currently in closed beta

Flutter / Dart · Supabase
Mobile & web · Currently in closed beta

THE PERSON BEHIND THE PRODUCTS

Practical roots.
A creative approach.

Before I was building apps, I was building things by hand, working with customers, and making music. A longtime interest in technology gave those experiences another outlet.

More about my background ↗

Hands-on work

Years in construction, manual labor, and customer service taught me to follow through, adapt when plans change, and build around the needs of the person doing the work.

Music & production

A life in music taught me to think in patterns, explore abstract ideas, and refine the details. I bring that same attention to the flow and feel of an app.

Technology & systems

I’ve always wanted to understand how things work. Creating and following systems turned that curiosity into a habit: break down a problem, make the next step clear, and keep improving it.

How I build and testPutting that approach into practice — with QA, security, and clear documentation

Those habits carry into my development process. I use an AI-assisted workflow, with hands-on ownership of product decisions, design, integrations, testing, and releases. Project records keep the reasoning, security work, and verification alongside the code.

PROJECT HQ

The plan, the work, and the proof.

  1. Feature specs & work queue

    Requirements, decisions, dependencies, and to-dos stay connected in each app’s HQ.

    Scope · tasks · acceptance criteria
  2. Security & change history

    Document access rules, track findings and fixes, and record why a feature changed.

    Permissions · feature updates · open risks
  3. Verification & next steps

    Keep test evidence and release notes with the work, including what still needs checking.

    Results · release records · follow-ups
QA IN LAYERS

Check more than the happy path.

  1. Logic & interfaces

    Automated unit and UI suites cover calculations, state changes, and layout regressions.

    Availability overlap · pricing rules
  2. Permissions & failure cases

    Role and database-policy checks, denied access, retries, and recovery paths.

    Sharing boundaries · failed sends
  3. The actual experience

    Browser and simulator checks for real journeys, screen sizes, navigation, and readability.

    Small screens · order flows · chat
EVIDENCE, NOT ASSUMPTIONS

A passing test is one part of the story.

  1. Tests
  2. Build
  3. Device
  4. Release

I record what was checked, where it ran, and what still needs verification. Device acceptance and a live release have their own evidence; security and feature updates keep their follow-up tasks attached.

Scroll or pinch to zoom. Drag to move. Double-click or double-tap to zoom or reset. Keyboard: plus and minus to zoom, arrows to move, zero to reset, Escape to close.

Tyler Abromeit