Skip to content
FSHNiSTA ← Back

The Build

Engineering log · Vienna · 008–001

Somebody bought something, and somebody got paid.
The first order and the first payout both cleared this month. Nothing about the platform is theoretical from here.

In June we wrote that the payment path was wired. This month it was walked. An order was placed, paid for, shipped, and the money reached the seller's bank account, with our commission taken out of the middle and the card fee taken out of our share, exactly the way we say it works. Two things we had been describing in the future tense are now things that have happened once.

Once is the right number to be honest about. It is not traction and we are not going to dress it up as traction. What it is, is the end of a category of risk. Every part of a payment that can only be tested by doing it for real has now been done for real: the charge, the split, the hold, the release, and the arrival.

9
Services running in production
3
Markets live from day one
0
Members admitted. The doors are still shut

Money should not move because somebody pressed a button

The first version paid a seller the moment a buyer tapped to confirm delivery. That is fast, and it is wrong twice over: most buyers never confirm anything, so sellers would have waited forever on silence, and the ones who did confirm could be paid before anyone had a chance to say the parcel was wrong.

Money now moves on a clock instead. A confirmed delivery starts a short hold; an unconfirmed one starts a longer one that runs from the day the seller posted it. Either way the seller gets paid without chasing us, and a buyer who opens a dispute stops the money the moment they open it. Two different clocks because we are waiting on two different things, and confirming is real information, so it should not cost a week.

Decision this cycle

A seller is paid in the currency the money actually arrived in, at the rate that charge settled at, never at a rate we hold. If we cannot read the real rate, we do not pay, because a guessed rate is somebody else's money. This is slower to build and it is the only version we could defend to a seller.

Product photographs are checked before they go on sale

Listing photographs are now screened before a listing can go live, not after. Nothing reaches a public page unseen. We tuned it against real garments rather than a default setting, which mattered more than it sounds: a generic filter flags swimwear, lingerie and anything cut close to the body, which on a fashion platform means flagging the product. It screens for harm. It does not have opinions about hemlines.

Both apps are in testers' hands

The iPhone and Android builds now go out together, from the same code, on the same day. That sounds like housekeeping. It is the difference between one app being tested and two apps quietly drifting apart, which is how a fix gets confirmed on one phone and shipped broken on the other.

Sellers can post an order from their phone now, and buyers can see where the parcel is. Both halves existed separately for weeks and neither was connected to the other, which is the sort of thing you only find by using the thing rather than reading it.

Still nobody has been let in. The waitlist is past a thousand people across four continents and every one of them is still waiting. We would rather open late than open with somebody's money in the wrong place.

We built our own map.
Discovery is the part of this platform a competitor cannot copy quickly, so we stopped renting it.

The Map is how a member finds a salon, a tailor, a stylist, a photographer or a model near them. Until this month it was drawn by Google, which meant our discovery surface was a product we rented, priced per view, and could not change the look or behaviour of. It is ours now. Our own map, our own tiles, our own type, no per-view bill and no third party sitting between a member and the people they are trying to find.

The cost of running it is a few cents a month. That is not the reason we did it, but it is a good illustration of what the rented version was: expensive, and not actually ours.

Decision this cycle

Results are never ordered by what a provider pays us. What a professional can buy is reach, meaning how far their listing carries, and never position in somebody else's results. A directory people cannot trust is a directory nobody uses twice, and there is no version of this we could reverse later.

The part that is actually hard to copy

Anyone can put pins on a map. What we spent the time on is what a pin says. A listing carries specialisms, so a hair salon can state that it works with type 3 curls, type 4 coily hair, locs, braids, silk press, colour on dark hair, barbering, and be found for those words specifically.

Search a mainstream map for a hair salon near you and it cannot tell you whether anyone there has ever worked with your texture. Neither can the big booking platforms, and neither can a hashtag. For a lot of people that is the entire problem, and it is not a small group: it is most of the people we have talked to while building this.

We also drew a line about who appears. A fashion or beauty business shows up on our map only if it is a member. Landmarks stay, so the map still reads like a map, but we are not scraping the neighbourhood and calling it a directory.

Nothing appears unseen

Content moderation went live this cycle. Images are screened before they reach anybody, and the appeal route exists at the same time as the enforcement, which is the order most platforms do it in backwards.

Next: the commerce side of that same rule, the first real order, and getting builds into testers' hands on both phones instead of one.

Our first service is live. The rest is queued behind it.
Real traffic, real infrastructure, and a three-market strategy that is starting to take shape.

For a long time, everything we built lived behind a wall: tested, working, but not actually live anywhere. That changed this cycle. Our first backend service is now fully deployed and handling real traffic. It sounds small written down like that. It is not small. It is the difference between "we built something that works" and "something we built is working, right now, for real."

Behind that first service, the rest of the platform's core infrastructure is built and tested: the tools for creators managing their digital identity, the storefront layer, the booking system for stylists and beauty professionals, wardrobe management, and the authentication layer holding it all together. All of it has passed its own tests. What is left is deployment, not development, which is a very different kind of remaining work than what we started this year with.

Decision this week

We are deploying services one at a time, in order of what unlocks the most for early members, rather than launching everything simultaneously. A platform that goes live in pieces, each piece actually working, beats a platform that goes live all at once with rough edges everywhere.

Three markets, not one

We have been deliberate about where FSHNiSTA launches first, and the answer has grown from one market to three. Vienna is home, and where the product is built and tested first. West Africa came next: a fast-growing fashion market with its own payment rails and its own creative energy that deserved to be a launch market on its own terms, not an afterthought.

The newest addition is North America. This one came from the market itself rather than from our own planning. Real interest from people who found FSHNiSTA and wanted in before we had even started building for that market. We are treating that seriously, and we are building the payment and compliance infrastructure a US launch actually requires, properly, rather than rushing a version that would need to be redone later.

Three markets with three different currencies, three different regulatory realities, and three very different fashion cultures. Getting that right from the infrastructure up is slower than pretending one system works everywhere. We are choosing slower.

The payment path is wired. So is search.
Checkout stopped being a placeholder. And for the first time, Google actually knows we exist.

Two things happened this week that matter more than they sound like on paper. First, the payment path is wired: an order can be priced, taken to a card, and pointed at the seller it belongs to, with our commission split out of it. Nobody has bought anything yet, and there is a difference between a path being built and a path being walked. Second, and less visible but arguably more important long-term, the site is now properly indexed. Sitemap submitted and verified on both Google Search Console and Bing Webmaster Tools. Structured data live. Every page has a real meta description instead of a generic one.

48
Pages indexed with unique metadata
2
Search engines verified and crawling
0
Orders taken so far. The path is built, not walked

Why SEO now, this early

It is tempting to think of search optimisation as a later-stage problem, something you deal with once you have traction. We think that is backwards. Google needs time to trust a new domain. The earlier we are properly indexed, the earlier that trust starts compounding. Waiting means waiting twice: once for the product to be ready, and again for the crawler to catch up.

Decision this week

We are treating discoverability as core infrastructure, not a marketing task bolted on later. Every new page shipped from here forward gets a meta description and social preview card before it goes live, not after someone notices it is missing.

On the commerce side, we also fixed something that had been quietly annoying: article links shared to WhatsApp or LinkedIn were showing a blank preview instead of the actual headline and photo. Small thing, but it is the difference between a link people click and a link people scroll past. Fixed now, every newsroom article shows its real title, excerpt, and image when shared anywhere.

Next up: the internal tools our own team needs to actually run this thing at scale, merchant verification and content moderation, so the platform stays trustworthy as more people join.

How the Test Flight opens. By hand, and slowly.
Why every application gets read by a person, and why nobody is in yet.

The Test Flight is not a launch and it is not a queue. Every application is read by a person, and members are admitted in cohorts rather than continuously. That is slower than an automated waitlist by an order of magnitude, and it is deliberate: the decisions taken on a platform in its first weeks become structural, and we would rather be in the room with the people taking them.

9
Services in production
1,000+
Waiting to be let in
0
Members admitted so far

That last number is the honest one, and it is the one we get asked about most. The platform is built and running on its own infrastructure. The doors are shut. We would rather say that plainly than describe a community that does not exist yet.

What the waitlist is already telling us

The pull is coming from the professional side harder than from the consumer side. Stylists, designers and small brands are the ones writing to ask when they can get in, and they are not asking about the feed. They are asking whether they can take bookings, whether they can list, and whether people will find them.

Decision

Booking Manager moves up the queue. It was planned as a second-phase focus, and the people actually asking for the platform are asking for it first. A tool that is valuable to one professional on their first day beats a social feature that only works once everybody has arrived.

Two fixes worth naming, because they are the kind nobody writes about: the size selector on mobile was not respecting the safe area on newer iPhones, so the last row sat under the home indicator. And removing an item from the bag while the panel was still animating could leave the bag in a state that disagreed with itself. That second one took a day to reproduce reliably, which is usually the sign that it was worth fixing.

Next: the doors stay shut until the things a first cohort would hit are finished rather than nearly finished. When that changes, it will be said here first.

Building the store. Why luxury ecommerce is harder than it looks.
The FSHNiSTA brand store, the payment path, and the surprisingly deep rabbit hole of product photography.

We decided FSHNiSTA needs its own merch. Not because we need revenue right now, but because the store itself is a product demo. Every visitor who buys a hoodie experiences the commerce layer firsthand. That is worth more than any feature description we could write.

The technical work this week was mostly the bag and the payment path. We used a hosted checkout for the first version, because European card payments have strong customer authentication rules to satisfy and that is not the part worth building yourself early. A custom checkout is worth it when volume justifies it.

Decision this week

We set a hard photography standard before shooting anything: one ratio, a clean background, and the subject filling most of the frame. Inconsistent product images are the fastest way to make a luxury store look cheap.

What took longer than expected

The cart state management. We wanted a bag that survived the visit but not the week, which sounds like one decision and is really several. The edge case nobody thinks about: what happens when somebody opens two tabs? The count in one can disagree with the other, and which of them is right is a question the browser will not answer for you. It reads as a small bug and it is really a question about where the truth lives. We added a storage event listener to sync across tabs. Small thing. Took three hours.

The store went up with eight pieces, all FSHNiSTA branded, on placeholder photography. It has since come down: the site rebuild removed it, because a merch store sitting on the front of a platform that has not opened yet was answering a question nobody was asking. The commerce work it proved out did not go anywhere. It moved into the product, where it belongs.

The platform vs product tension. How we are thinking about what ships first.
FSHNiSTA is a platform with ten user types. You cannot build everything at once. Here is the framework we are using to decide what comes first.

The hardest thing about building a platform is that its value is proportional to who is on it. The Digital Twin is more useful with more brands. The Map is more useful with more stores. Creator content is more compelling with more products to link to. Everything depends on everything else.

You cannot launch everything simultaneously. You have to pick an entry point and build outward from it. We spent most of this week getting explicit about what that entry point is.

Our answer: creative professionals first

Stylists, photographers, models, designers. They are underserved by every platform they currently use. The friction in their workflow is genuine and solvable with what we already have. A stylist who can take bookings, show their portfolio, and get discovered on one platform has an immediately better working life. That is a real value proposition that does not depend on network effects to deliver.

Framework we settled on

Build features that are valuable to a single member before they have any Lookers. If a tool only works at scale, it is not the right tool to ship first. The Booking Manager, the portfolio system, the Map Discovery module all clear this bar. The social discovery features do not, so they come later.

This framework has been useful for prioritisation arguments. When someone suggests a feature, the first question is now: is this valuable to one person on day one? If the answer is no, it goes in the backlog with a note about what threshold it needs before it makes sense to build.

Why we started this journal. And what we are actually building.
The first entry. Why building in public, why Vienna, and what FSHNiSTA is trying to be.

Most companies build in private and announce when something is ready. We considered that. The problem is that "ready" is a moving target and announcing a finished product means you learn nothing from the people who would have shaped it during development.

So we are building in public. Not livestreaming our git commits, not narrating every meeting. But publishing a weekly entry about what we decided, what we built, what broke, and what surprised us. The people who read this are exactly the people we want on the platform.

What FSHNiSTA actually is

The short version: members get a Digital Twin and see a garment on it before they buy, and find the salon, tailor or stylist whose work matches theirs. Sellers get a storefront, a booking calendar and a pin on the map. The longer version requires understanding what is broken about how fashion works today. Every player in the industry: consumers, creators, brands, retailers, designers, stylists, photographers, models, beauty professionals, media, builds on a completely separate stack. Nothing talks to anything else. The consumer who tries on a garment in a brand's app cannot take that data to the next brand's app. The stylist who builds a portfolio on one platform cannot book appointments through it. The model who licenses their image does it through a management company that takes forty percent.

The core thesis

If you build the infrastructure layer that connects all of these players, the value compounds in every direction. The consumer's Digital Twin gets more useful as more brands integrate. The designer's storefront gets easier to find as more people carry a Twin. The stylist's discovery improves as more consumers use the Map. This is what a platform is supposed to be. FSHNiSTA is the first attempt to build it specifically for fashion.

We are based in Vienna. The city was a deliberate choice: engineering talent is strong, the startup ecosystem is underrated, and we are geographically centred for the European markets that matter most to fashion. The idea started in 2024. The company itself took until November 2025 to exist, most of that spent waiting on paperwork rather than on anything we were doing. FSHNiSTA GmbH has been registered at the Handelsgericht Wien since then, and we have been building throughout.

This journal is updated when there is something real to report, which has worked out at every few weeks. We would rather skip a month than pad one. The goal is honesty about what the build actually looks like, not a highlight reel. If you want to follow along or get in touch, the waitlist is open.