The company
We were the customer before we were the company.
Sokocode did not start with a market study. It started with an invoice for software that was losing us money every morning.
A working practice, a diary full of holes, a plugin that had already been paid for, and nobody on the other end of the email. Everything this company refuses to do is something that was done to us first.
What that taught
Two problems, and only one of them was software.
The first was money
Customers booked, received their polite reminders, and simply did not arrive. The number was nameable to the rupee, every month. No plugin on the market did anything about it, because none of them could receive a reply — which is an architectural fact, not a missing checkbox.
The second was worse
When something broke, the answer was a ticket queue, a request to clear the cache, and days of silence while the booking page stayed broken and the phone rang at reception. Paying more had not bought anyone who cared.
Those two experiences are why the covenant exists, and why it is written down in public before we have sold anything. A promise made after the money has changed hands is a marketing message. Made before, it is a constraint.
How we build
Ten rules we actually follow.
Our plugins will not always be in the same category. The method is what makes the second one trustworthy on the strength of the first.
The customer’s experience comes first
Every feature earns its place in the screen your customer sees and the screen you work in. Competing plugins are cluttered because nobody ever said no. We say no.
A feature is implied by data, never by a toggle
The practitioner step disappears below two practitioners. The coupon box appears when a live coupon exists. If the software can work it out from your data, it should not be asking you.
Prefer deleting to adding
The best version of a change removes a branch rather than adding one. The smartest solution is almost always the shortest correct one, not the most general one.
Guarantees belong in the database
Constraints the database enforces under its own locking, not conditions PHP re-checks afterwards. A unique index makes a thing impossible; careful code only makes it unlikely.
Security is structural, never bolted on
Parameterised SQL, a nonce and a capability check on every action, output escaped at the point of use, and money recomputed on the server every single time.
Abstract on the third case, not the first
No interface with one caller. Two similar things are a coincidence; three are a pattern. Building the abstraction early is how a codebase becomes elaborate before it becomes useful.
Make a wrong assumption visible
A guard that fails loudly beats defensive code that hides the problem. The importer refuses by name when a column is missing rather than importing nothing and calling it success.
Reuse a setting before inventing a second one
Two settings that mean the same thing will disagree eventually, and the person who has to work out which one won is you, at the worst possible moment.
Say what is not built
Roadmap items are labelled as roadmap, and there is a page on this site listing what has never run in production. We would rather tell you than let you find out on a Tuesday.
Refuse the tempting things
Some features sell well and should not exist. No symptom triage, no dark patterns in a cancellation flow, no add-on shelf. Saying no to those is most of what makes the rest trustworthy.
Where we are
Three companies, three continents, one product team.
Not a head office with sales offices. Three registered entities, because selling software to a clinic in Ohio, a salon in Rotterdam and a physiotherapist in Pune are three different legal and tax problems — and solving them properly is what lets us charge one price and settle it locally.
The billing entity for the Americas. Dollar pricing, US tax handling, and the contracting party for customers who need one on their side of the Atlantic.
The European entity. Euro pricing, EU VAT handled properly rather than approximated, and GDPR answered from inside the union rather than about it from outside.
Where the engineering is. Rupee pricing set for what an Indian business actually pays, GST invoicing with your GSTIN on it, and the people who write the code.
One product, one roadmap, one support inbox. The entities exist so that the invoice is correct wherever you are — not so there is somebody different to talk to.
Who builds it
Ten years of engineering, and one plugin to show for it so far.
Six hundred and seventy projects shipped across fifteen countries before this one — client work, which teaches you what breaks in production and nothing at all about running a product company. We are learning the second half in public.
The three of us
Three people, and you can have all their addresses.
Most plugin companies put a stock photograph of a boardroom on this page. Ours names the three people who write the code, decide what gets built and answer the email — because “the engineer who wrote it replies” is only worth saying if we are willing to say who.
Chief executive, and still an engineer. A technology leader and entrepreneur with over twenty years across software engineering, quality engineering, cloud, DevOps, automation and AI.
He has worked with Microsoft, Amazon, Google, Adobe, Symantec, Zillow, Alcon, Vertex and Thryv. As founder and CEO of Imagistack he built and scaled a 40-plus member technology company serving clients across the United States, the United Kingdom, Germany, France, Italy, the Netherlands and India — which is where the 670-plus projects and fifteen countries on this site come from.
He combines technical depth with business strategy, customer focus and team leadership, and now works on getting organisations to adopt AI, automation, cloud and modern engineering practices without the theatre. Sokocode is the first time that has been pointed at a product of our own rather than a client’s.
Chief product and innovation officer, and still an engineer. A serial entrepreneur who has started, funded and run companies for two decades, and who owns product direction, user experience strategy and what gets built next.
He has built businesses across farming, shipping and public policy — three industries where the software was never the hardest part. The crop that will not wait, the container that is late, the rule that changes in April: each one teaches you that a product is judged on the week a business actually has, not on the feature list it was sold with. That is the lens every item on the roadmap is held up against.
He is hands-on with hardware as much as with interfaces, and the habit of building a thing you can hold is what keeps product decisions honest about what a real counter, a real queue and a real pair of hands can do. On this product it shows up as the refusals — no settings toggle where the data already knows the answer, and no feature that demonstrates well and helps nobody.
Chief technology officer, and still an engineer. A technology and creative leader with nearly two decades across frontend engineering, UI/UX, mobile applications, cloud platforms, AI-enabled solutions and digital product design.
His expertise spans React, JavaScript, TypeScript, Next.js, Node.js, mobile-first development, cloud-based architectures, Figma and the Adobe Creative Suite. He brings design thinking, user research and modern engineering together to build products that are intuitive, scalable and commercially effective rather than merely feature-complete.
He has led multidisciplinary projects from product strategy and prototyping through to frontend implementation and delivery, working with clients, stakeholders and engineering teams to turn business requirements into high-quality web, mobile and AI-powered experiences. On this product that shows up as the rule that a feature is implied by your data, never by a toggle.
Why we started
We were the ones swearing at the plugin, first.
Ten years of building sites for other people, and the same week kept repeating. A plugin that did eighty per cent, and a checkout page telling us the last twenty was four add-ons away. Twelve plugins from twelve vendors, so the Tuesday one of them updated was the Tuesday the booking form stopped taking payments. Support that asked us to deactivate everything else and try again — on a live site, with the client on the phone. Forty settings to configure before anything worked, and a licence that lapsed and switched the plugin off, taking the shop with it.
None of it was our client’s problem
They had a business to run. They did not care which vendor shipped the bad update, or that the feature they assumed was included had always been an add-on. They cared that Tuesday’s appointments were gone. Every hour we spent holding somebody else’s software together was an hour nobody was paying for and nobody wanted to buy.
So we built the plugin we kept wishing existed
Seasoned engineers, building fewer and deeper: everything in one subscription, hardened and run against real bookings before it goes out, and a user interface a receptionist can work without being trained on it. Not features on a comparison table — the actual jobs a business has to get done on a Tuesday morning.
The whole point is that you stop thinking about the software. You should be running your business, not maintaining the thing that runs it.
Judge it on the work
Origin stories are cheap. The plugin is not.
Every plugin company has a founding story. Install ours beside whatever you run now, on the free plan, and decide from what you see.