About
We started because too much software is shipped and then abandoned.
We are a small senior team that designs, builds and runs software — including our own product, Passlay. Here is how we got here and how we work.
Our story
Founded 2019
Nibble Square began with a small team who had spent years watching well-funded projects arrive late, launch loudly, and then quietly rot. The pattern was rarely a lack of talent. It was software built by people who would never have to live with it.
So we built the company around the opposite arrangement. We stay close to the thing we make. We run our own product, Passlay, in production — which means we carry a pager, answer support tickets, and feel every shortcut we were tempted to take. That experience shapes how we build for clients.
Today we are a small senior team taking on a deliberately limited number of engagements at a time. We would rather do a handful of things properly than staff a pipeline.
What we stand for
How we approach building software
These are the things we actually argue about internally, not a poster in a hallway.
Build things that hold up
Software is judged on the day something goes wrong, not the day it launches. We build for the second one — tests, monitoring, sensible failure modes, and no clever tricks nobody else can maintain.
Say the inconvenient thing
If a feature is a bad idea or a deadline is not real, you will hear it from us early. We have talked clients out of work more than once, and it has never cost us a relationship.
Understand the work first
We start by learning how the job is done today, including the workarounds. Most bad software comes from skipping that step and building what was asked for rather than what was needed.
Leave it maintainable
Every engagement ends with documentation, tests and a team that can carry it on. We are not interested in being a dependency.
Work in the open
Progress, blockers and estimates stay visible throughout. No status theatre, no surprises in week eleven of a twelve-week project.
Treat it as a partnership
We work directly with the people who use what we build, and stay past launch. The interesting problems only show up once real users arrive.
How we work
Four steps, every engagement
Deliberately unglamorous. Most projects fail in the first step, not the third.
- 01
Understand
We sit with the people doing the work, map the current process end to end, and find where the real cost is. Usually it is not where anyone expected.
- 02
Shape
We turn that into a scoped plan with an architecture, a sequence and honest estimates — including what we would cut first if time gets tight.
- 03
Build
Two-week cycles, working software at the end of each one. You see progress continuously rather than at a milestone review.
- 04
Run
We launch, watch what real usage does to our assumptions, fix what breaks, and hand over something your team can own.
The team
Who you will actually work with
No account layer, no bench. Every engagement draws on this same set of disciplines, end to end.
Genius Business Analysts
Turn a vague brief into a requirements doc that survives contact with engineering. They ask the questions that save you six weeks later.
Awesome Product Owners
Own the roadmap and the trade-offs, so scope creep gets caught in planning instead of in production.
Intelligent Art & Graphic Designers
Design the interfaces and brand assets that make software feel considered, not assembled.
Brilliant Software Architects
Make the calls on structure and scale before the first line of code, so the system holds up under real load.
Sharp Data Scientists
Build the models and the evaluation sets that prove they work, not just demo well.
Meticulous Quality Assurance
Break the build before your users do — test plans, edge cases, and the paths nobody thought to check.
Want to know how we would approach your problem?
We are happy to talk through a project before there is any commitment on either side.
Currently booking projects starting next quarter.