Zeltta iconZeltta logo image

Our Philosophy

The delivery of any product or service can be split into two phases. The first phase, "research and development" is achieved through a learning and discovery process like the scientific method, where the goal is to learn how to make it work. The second phase, "production", is best achieved through detailed planning and control, where the goal is to maximize output and quality.

Usually the second "production" phase takes much more effort. Building, manufacturing, or executing a plan is usually much more complex and time-consuming than making one. Most of us spend the majority of our working lives organizing or completing well-defined production processes.

As a result, everything we learn about how to manage a project or run a business is geared towards "production" thinking. We then run into problems when we apply our "production" way of thinking to a "research and development" project. These projects often relate to intellectual property. For example, Writing, Design, Investing, Music, Films, Scientific Research, and of course, Software.

Software has no production phase, the computer just clones a bunch of bits. 50% of software projects fail and tiny startups routinely steal industry leadership from powerful corporations because people always try and fail to fully scope a software project upfront and work backward to complete it - as if it were a 100% predictable and controllable process.

Software is not predictable or controllable, it is built on the fly out of thoughts and decisions about how to connect, channel and display information. Without a feedback loop of build, test, learn, a software project is dead. The idea that you can start out by learning everything you need to know in order to build a complete software system is an illusion. That's because it's easy to estimate what you know, it's hard to estimate what you know you don't know, and it's impossible to estimate what you don't know you don't know.

There are two solutions, the first one is based on trust and transparency, the second one is based on us taking all the risk. In the first option, we basically charge hourly, tell you exactly what we did, what was learned and we'll ship whatever is completed at fixed intervals. In the second option, we'll price the entire project upfront but it will include a large margin of safety to cover our ownership of setbacks, rewrites, bugs, and minor changes.

Our principles

To get a higher rate of success in our projects we follow the following principles:

  1. We prioritize tasks by risk elimination not sequentially. We'll isolate and solve the hardest problems first and then put everything together once we know how they can fit nicely.
  2. Evolution, not assembly. There is a big difference between something that works and something that works well. (Think Blackberry vs iPhone). We don't just check off features on a checklist once they "work", we evolve products flexibly over several iterations to get them working beautifully.
  3. Conversation of complexity. For every improvement of user experience, there is an equal and opposite increase in the complexity of the code. Making something work mind-blowingly well often takes 10x more effort than just making it work (Movies vs Home Video).
  4. The paradox of choice. The time it takes to make a decision is a result of the possible choices. Therefore, the more narrow user requirements, the easier to use the product will be.
  5. Principle of least effort. The adoption of something is exponentially proportional to how easy it is to use. Software projects fail often because they try to do too much and run out of momentum before they reach the tipping point for ease of use/adoption.
  6. 80/20 Rule. 80% of a software system will be written in 20% of the time, the hardest 20% of the code will take up 80% of the time, and 80% of users will only use 20% of the product. The single most cost-saving activity in a software project is the refinement of the scope through prioritization and elimination.
  7. No design by committee. The more people you include in product/feature decisions, the worse your product will be. Follow diversity in counsel, unity in command. Focus on your customer and their most important problem, hold the full vision yourself, and we'll back you all the way.
  8. Van Loon's Law. The amount of mechanical development will always be in inverse ratio to the number of slaves that happen to be at a country’s disposal. Innovation only happens when constraints exert enough force on something to be improved. Make sure you ask the right questions from the right people.
  9. Communication paradox. Communication isn't improved by making it more efficient but by eliminating the need for it. We tend to overestimate how much users understand a product and how it works. Instead of exhausting ourselves through emails, meetings, and calls, we should build self-serve resources like FAQ pages and product roadmap boards to show the status of tasks.

Our process

Step 1 - Get in touch

We'll need to get a little more information about your project before we can give you an accurate quote, so please contact us and we'll make an appointment for a call or face-to-face meeting.

Step 2 - Call or face to face meeting

We'll discuss your project, and explain what we can do for you. We'll also ask you a number of questions about your goals for your product or service and discuss how to use digital technology to create the types of features you'll need.

Step 3 - Build Plan / Quote

After the meeting is over, we'll create a quote and email it to you for review. The quote will contain

  • The costs involved in developing, building, and launching a working prototype
  • A rough timeline
  • The team we'll use
  • The features included
  • The regular monthly costs for hosting, support, and maintenance

Step 4 - Sign contract

When you're happy with the quote, we'll sign a contract and start work on your product or service.

Step 5 - Strategy & requirements

We'll take some time to think about the strategy and requirements for the product or service. This might include an audit of your existing operation, a review of the competitive landscape, or research into the best ways to meet your goals for the product or service.

Step 6 - Solution architecture

We'll create a solution architecture and tech stack for the product or service. This will include making decisions about the architecture, and the technologies we'll use to build it. We'll also need to make decisions about the design of the product so that it meets your goals for the product or service.

Step 7 - User interface design

We'll begin work on the user interface design for the product or service. We'll work with you to agree on the user flow, layout, and structure of the product or service before we begin work on the visual design of it.

Step 8 - Development begins!

We'll start building the product or service. We'll produce regular updates and send them to you, so you can see how we're progressing.

Step 9 - Launch or test

When we're ready to launch the product or service, we'll work with you to plan the launch schedule and identify the goals for the launch, before we start working on the rollout.

Step 10 - Repeat Steps 7-9

Rather than trying to build your final product in one big risky and ill-informed leap, we would rather evolve it through multiple separate phases, each one building on all the lessons before. Remember, software is much more a process of learning and discovery than planning and control. It's better to make sure something works and improve it than it is to spend a huge amount of time and effort only to find out that a core assumption was wrong.

Zeltta iconZeltta logo image
Zeltta Limited © 2022
Hamilton New Zealand
News & Resources