Karl A L Smith

human knowledge belongs to the world

All me Privacy by Default

Why All me app has no deadlines

Context of Decision

The Founder of All me Karl A L Smith has a long consultancy career focusing on solving complex problems. His work includes many sectors but this decision is based upon both the unique selling point (USP) of All me and his consultancy experiences. In the 1990’s the Founder was involved in Base Security in the United Kingdom of a US small company based in Virginia during a site visit he learned something about deadlines that completely changed his perspective on them.

 

I was on a RAF base servicing the USAF base within it during the 1990’s, going to the entrance I was met by a young soldier with a machine gun who was to escort me to the building within the complex where I was to work. As we traversed the base I noticed a Red line (we were walking on a pathway delaminated by yellow lines) and I asked him “what is that”, he said “its a deadline”. I was confused so asked “what happens if i cross it?” he said “a sniper will kill you”. And that is when I understood what a deadline is, its a point of no return. Karl A L Smith

 

While the use of deadlines can have a positive impact on the progression of work All me is adopting an Agile and iterative based approach to everything in order to learn by doing. Karl A L Smith is an Agile Thought Leader having been involved in it since 2003, leading major transformations in adaptive strategy, delivery, governances, regulatory compliance and has decided to build All me using its principals by adopting Customer Agility but excluding the AI components as it would breach All me Privacy by Default requirement.

No Deadlines is a Deliberate Strategy in All me Software Development

From broader software-development practice, there are well-known arguments against rigid, fixed deadlines — especially for complex or evolving products like apps. Some reasons:

  • Uncertainty and learning: Software development is often exploratory. Requirements change, new issues crop up, features evolve. Imposing a fixed deadline from the start can lead to rushed work or cutting corners.

  • Quality over speed: If developers are pressured to meet a deadline, they may skip proper testing or take shortcuts. This creates “technical debt” — code that works now but causes problems later.

  • Unpredictability of scope and complexity: For complex projects, estimating exactly how long something will take is difficult. Deadlines based on early estimates often turn out to be unrealistic once development starts.

  • Agile / iterative approach: Many modern teams prefer iterative development (small releases, incremental improvements) rather than a “big bang” release. In such approaches, the emphasis is on regular delivery cadence rather than a single fixed launch date — making rigid deadlines less relevant.

  • Avoiding burnout / preserving team health: Strict or frequent deadlines often lead to “crunch time” (periods of intense work), which can cause burnout, reduce long-term productivity, and degrade code quality.

Because of these issues, some projects especially newer, privacy-focused, independently funded ones might choose to operate without rigid deadlines. Instead they may prioritise correct design, flexibility, and sustainable pace.

  • All me is built around privacy, user-control, and architectural complexity (multiple independent profiles, strong data separation, secure payment routing, etc.). That means more careful design and testing — rushing such features could undermine the values they claim.

  • As an independent or startup project (not a huge corporate-backed social network), they may have limited resources; forcing a deadline could jeopardise quality or lead to technical debt, which would be risky long-term.

  • Our goal is to iterate, test, adapt, rather than just launch a minimal product for hype,then a more flexible, milestone or feature-based roadmap (rather than calendar deadlines) makes more sense.

Pros & Cons of “No Deadline” Approach

ProsCons / Risks
More flexibility to iterate, respond to feedback, improve privacy / design.Harder to commit to a launch date — might frustrate early adopters or investors expecting a release.
Less pressure on developers ? better quality, less burnout, fewer shortcuts.Without a deadline, development may drag — features may be delayed indefinitely.
Avoids technical debt from rushed coding or testing.Might be perceived as vague / unprofessional by prospective users if there’s no clarity when app will ship.
Easier to adapt to changing ideas / requirements (especially for a social-privacy app)Risk of losing momentum or losing public interest if progress seems slow or uncertain.
Total Page Visits: 46 - Today Page Visits: 2