v/01
Ship weekly, not eventually
Software that is not in someone’s hands is a rumour. We keep the deployable build deployable, every week, from the first week — even when it only does one thing.
About the studio
About
BasilBase exists because there was a gap between “hire a freelancer and hope” and “sign a six-figure agency contract and wait”. We fill it with a senior, deliberately small team that scopes honestly, builds in the open, and hands you everything at the end.
We are twenty-four people who like small software
BasilBase exists because there was a gap between “hire a freelancer and hope” and “sign a six-figure agency contract and wait”. We fill it with a senior, deliberately small team that scopes honestly, builds in the open, and hands you everything at the end.
The short version
We started in 2019 as two engineers taking on rescue work: half-finished apps, abandoned codebases, projects where the previous team had stopped answering email. It was unglamorous and it taught us the single most useful thing we know — almost every failed software project failed at the scoping stage, months before anybody wrote a line of code.
So we built the studio around scoping. Every engagement starts with a paid block where the only deliverable is clarity: what the product actually has to do, what it does not need to do yet, what will be technically painful, and roughly what the whole thing costs. Clients can take that document and walk away. Some do. The ones who stay know exactly what they are buying.
Today we design, build, ship and maintain micro-SaaS products and mobile apps — the small software businesses that support a team of two to twenty people rather than a venture round. We are not trying to become a hundred-person agency. Growth beyond about thirty people would break the thing that makes this work: everyone here has shipped, everyone talks to clients, and nobody hides behind a process.
What we are not
We are not a body shop — you cannot rent an engineer by the month to sit in your standups. We are not a design agency, although we have designers. We do not build marketing websites, we do not do SEO retainers, and we do not take on enterprise integration programmes with fifteen stakeholders and a steering committee. Saying no to all of that is what makes the yes fast.
How we run the studio day to day
Two projects run at a time, maximum. Each has a product lead, a designer and two or three engineers, and nobody is on more than two projects. That constraint costs us revenue and buys us the thing clients notice most: when you message someone, they know what you are talking about.
We work in two-week cycles. Monday of week one is planning, the second Friday is a live demo with whoever from your side wants to attend. Between those, the board is public, the build is deployable, and the daily notes are written rather than spoken so nobody has to be online at a particular hour to stay informed.
Everyone in the studio talks to clients. There is no account management layer, because the translation losses between “what the client said” and “what the engineer heard” are where budgets die. It also means bad news reaches you fast, which is uncomfortable exactly once and valuable every time after that.
Where we work
We keep one office and a team that overlaps for several hours every working day, because fully asynchronous engineering makes small teams slower rather than faster. Replace this paragraph with your own location, working hours and time zone once they are decided.
The studio in numbers
2019
Founded
24
People
140
+
Products shipped
68
Live store listings
11
M+
End users served
4
Time zones
Every number above is countable and we will show you the working if you ask. We do not publish “satisfaction scores” because nobody has ever been able to explain how they were calculated.
How we behave
Six rules we actually enforce
These are not poster values. Each one has a consequence attached: if we break it on your project, you can point at this page and we will fix it at our cost.
v/02
Own the outcome, not the ticket
Nobody here has ever said “that was not in the ticket”. If the feature technically works but the user cannot find it, the work is not finished.
v/03
Boring technology, bold products
We spend our novelty budget on the product, not on the database. Proven, well-documented tools mean your next developer can read the code without a séance.
v/04
Write it down
Decisions live in short written records, not in a meeting somebody missed. It makes handover boring, which is exactly what handover should be.
v/05
Say the number early
If something will cost more than you expect, you hear it the day we know — not in the invoice. Bad news does not improve with age.
v/06
Small teams, senior people
Four people who have shipped before beat twelve who are learning on your budget. We keep teams small and we keep them accountable by name.
History
Seven years, told honestly
Including the years where we were small, broke and learning in public. Studios that only publish the good quarters are hiding the part you can learn from.
2019
Two people and a rented desk
BasilBase started as a contract engineering pair taking on the builds nobody else wanted to finish. The first year was mostly rescue work — which is where we learned what a bad handover really costs.
2020
First category ranking
A utility app we built for a two-person client reached the top ten of its App Store category. We learned more from its one-star reviews than from the launch itself, and rebuilt our QA process around them.
2021
The pivot to micro-SaaS
We stopped selling hours and started selling shipped products with subscriptions attached. Billing, entitlements and churn analytics became part of every default build.
2022
Design brought in-house
Outsourced design was costing us two weeks per project in translation. Hiring our own designers cut MVP delivery from nine weeks to six and made the handoff argument disappear.
2023
An AI practice with guardrails
We started shipping model-backed features — and just as often talked clients out of them. The rule we adopted: no model in production without an evaluation set and a cost ceiling.
2024
The hundredth product
Product number one hundred shipped in March. We marked it by publishing our internal scoping checklist, which is still the most downloaded thing on this site.
2026
Twenty-four people, four time zones
The studio is distributed but overlaps for at least four hours every day, because asynchronous-only engineering makes small teams slower, not faster. We still cap projects at six people.
The people
Who you will actually be working with
No stock photos and no “consultants” who vanish after the sales call. These are the people who show up to your kickoff, write the code and stand in front of the demo every second Friday.
Elif Karaca
Founder & product lead
Runs discovery and scoping, and writes the blueprint document every project starts from. Spent eight years building payment products before deciding smaller software was more interesting.
Istanbul · 14 yrs
Deniz Aydın
Chief technology officer
Owns architecture decisions and the rule that we do not adopt a technology we cannot hire for. Reads every pull request that touches money or authentication.
Berlin · 16 yrs
Mert Solak
Lead iOS engineer
Has shipped more than thirty apps through App Store review and keeps a private list of every rejection reason encountered since 2017. That list is why…
Izmir · 11 yrs
Nadia Öztürk
Head of design
Builds the design system before the pretty screens, and insists on designing empty states, error states and the smallest supported phone first.
Istanbul · 10 yrs
Caner Bilir
Android & cross-platform lead
Kotlin, Compose and Flutter. Obsessive about cold start times and about testing on the cheap devices that make up most of the install base.
Ankara · 12 yrs
Sofia Marín
Growth & store optimisation
Writes the store listings, runs the screenshot experiments and reads the retention curves with clients every month. Believes most churn is a product problem wearing a…
Valencia · 9 yrs
Tolga Ersoy
Platform & reliability
Runs the deployment pipelines, the monitoring and the on-call rota. Keeps a running tally of how much each product costs to host per paying user.
Istanbul · 13 yrs
Ayşe Demirel
Delivery manager
Protects the two-week cycle from scope creep in both directions, and makes sure the demo on Friday actually happens on Friday.
Bursa · 8 yrs
Team members are edited under “Team” in the admin sidebar — add a photo, a role and a short bio.
Ground rules
The parts of working with us that people check twice
Things we will not do
- Quote a fixed price for an unscoped project
- Hold your accounts, code or data hostage
- Staff a project with people we would not hire again
- Bill for meetings we called to fix our own mistake
- Publish your project as a case study without written approval
- Take on work we do not believe will succeed
Working with us as a non-technical founder
About half our clients cannot read the code, and that is completely fine. We translate every technical decision into the trade-off underneath it — cost, time, risk, or what breaks later — and we never ask you to approve something you do not understand. If a recommendation cannot be explained in plain language, it is probably a bad recommendation.
In practice that means demos instead of status reports, written summaries you can forward to a co-founder, and an open invitation to ask “why” as many times as you need to.