The permissions system had two settings: edit everything, or edit nothing. For a software tool serving employees, vendors and clients, that could sound like an unfinished specification. At Konsult, it became the first version. Co-founder Jing Jin described how the consultancy tested that stripped-down arrangement with its client, SilentPartner, and found it sufficient for the MVP. The extra layers could wait.
There is something pleasantly unglamorous about that example. The team was deciding how much software a business actually needed. In an industry where the next feature is easy to imagine, Konsult’s story is an argument for paying attention to the one that never reaches the build.
The company’s public identity is straightforward: a San Francisco consultancy offering software advice, websites, applications and UX/graphic design. Founded in 2012 by Matt Delaney and Jing Jin, both with Apple experience, it described a preference for very small teams. Its work belongs in the market for custom product development: businesses buying the expertise to turn an idea or operational need into usable software.
The business of making the brief smaller
A startup hiring a development team faces two purchases at once. It needs people who can produce the software. It also needs someone to interrogate the brief. Those jobs can pull in different directions: every proposed capability offers more work, while questioning it might shrink the project. Konsult’s published approach gives unusually concrete weight to the second job.
Jin’s 2015 account of the SilentPartner project ties the simpler permission model to an earlier, cheaper release. Read that as a specific client decision. It does not establish that two access levels suit every business application, or that fewer features automatically make better software. The useful part is that the team tried the smaller version with the client before expanding it.
“Your MVP has too many features.”
Jing Jin · June 2015
For a buyer, the practical question is whether the proposed team will challenge requirements with equal care. Imagine a brief demanding three dashboards because there are three job titles. Before commissioning all three, ask which actions actually differ. A title on the organization chart is a reason to investigate a workflow; it is not, by itself, a software specification.
That is where this approach has a boundary. If a vendor must change one record while being barred from another, the simplified model no longer answers the requirement. The lesson to copy is the examination of need. A working shortcut depends on the conditions that make it acceptable, and those conditions deserve as much attention as the shortcut itself.
Apple experience, a different kind of deadline
Delaney’s public career profile connects Konsult with a broader engineering background, listing Apple and Google alongside founder roles at Blue and Marble. Jin’s speaker biography describes a master’s in human-computer interaction from Carnegie Mellon and a career beginning at Apple. Together, those backgrounds help explain the firm’s interest in both the workings of a product and the experience of using it.
Technical depth was visible early. At JSConf EU in Berlin in 2012, the founders jointly presented a session on WebKit, the browser engine. Their subject was the machinery behind familiar web frustrations: rendering behavior, animation timing and style recalculations. The talk’s title, The Web’s Black Magic, supplied the joke. The subject matter supplied the credentials.
This matters when evaluating a studio whose service list includes design. The appearance of a screen and the behavior of a browser are connected problems. A discussion about movement or responsiveness can quickly become a discussion about implementation. The conference appearance offers a concrete glimpse of what these founders were prepared to explain to other developers.
Konsult also described open-source development and speaking as part of its culture. That positioning makes sense for a consultancy: the people doing the work are much of what a client is buying. A public explanation of a technical problem lets a prospective customer inspect some of that expertise before a proposal arrives.
One month, and a chat app with a familiar name
Jin’s account of Konsult’s development process describes a client iPhone app called Yo!, explicitly distinguished from the famous namesake. It used timed chats. Once the team settled how a conversation moved from its current list to its past list, engineers could build that behavior while the interface was still taking shape. Jin put definition, design and construction at one month.
The mechanism is easier to understand than a promise to work faster. Some decisions unlock other work; some merely refine it. A team can agree what happens when a conversation expires before choosing exactly how the screen will communicate that event. The difference is between a dependency that blocks progress and a detail that can mature alongside it.
Shape the interaction
Build the behavior
A reasonable inference for clients is that access to decision-makers becomes part of the delivery model. If every question must travel through a long approval chain, overlapping work can turn into overlapping guesses. The attractive part of a small team is the chance to resolve uncertainty quickly. The client has a role in making that possible.
The commercial fit is therefore fairly precise. Konsult’s documented early work addressed startups trying to get an initial product into use, including products intended for investor presentations. An internal business tool sits alongside that work because the underlying need is similar: turn an incomplete understanding of a problem into something people can try.
The expensive part can happen before the bill
A revealing price in Jin’s writing is $15: admission to an event where a product manager interviewed three people about Watcha Doin’, an app from her wider consulting experience. Her essay on user studies says those conversations exposed recurring usability problems. The amount describes one research outing, not the cost of commissioning an application.
The same essay describes an unnamed startup that waited months to test its product, then discovered fundamental problems. The account stops at the difficult choice this created: discard substantial work or proceed despite the findings. It is a warning about the timing of evidence, rather than a documented story of a failed launch.
For anyone comparing development proposals, that distinction changes what “cost” means. A quote prices a defined body of work. It cannot make the underlying assumption true. Spending carefully therefore includes deciding which uncertainty must be resolved before the next substantial commitment, whether the work is performed by a consultancy or an internal team.
Consider a hypothetical booking application. A polished calendar would be a poor first investment if the unanswered question is whether customers understand the service being booked. A small exercise centered on that decision might be more informative. If scheduling itself is the uncertain behavior, then the calendar deserves attention. The experiment follows the question.
Simple feedback has limits, too. Friends can reveal a confusing label; they cannot stand in for every specialized buyer. The more a task depends on professional knowledge, the more carefully the participant should match it. That is an editorial implication of the approach, not a claim that a handful of interviews predicts commercial demand.
A service business with something readers can borrow
Konsult’s business model centers on client work. The buyer receives development and design services applied to a particular brief. Its natural alternatives include another product studio, a collection of freelancers or hiring a team internally. Those options should be compared against the same problem: how much coordination and product judgment the buyer needs along with implementation.
In the final installment of her 2015 series, Jin recommends matching the scope to the immediate goal, reusing established solutions for secondary needs and arranging work so disciplines can progress together. She also separates a prototype for a pitch from a product built for actual use. That distinction should remain visible in the brief and in the expectations around delivery.
Here is a practical way to apply that thinking. Write down the decision the first release must enable. Then ask each proposed feature to justify its place against that decision. Identify who can approve a change, which assumptions need an experiment and what must be dependable on release day. This is a suggested exercise, not a reconstruction of Konsult’s contracts.
The resulting conversation should be more useful than a race to produce the longest feature list. It gives the designer a purpose, the engineer a boundary and the buyer a basis for judging the result. It also makes a deferred feature easier to discuss: someone can explain what evidence would bring it back.
Konsult’s small permission system remains a good place to end that conversation. It puts an abstract argument about efficiency into a form anyone can understand. The first version had a job to do. The team gave it enough software to do that job, then let the client’s experience inform what belonged next.