Superior is a premium developer and designer, working with top brands and companies globally, building digital systems that dominate the market.

80 Market Street, South Melbourne, VIC, 3205 Australia
30 N. Gould Street, Suite 7711. Sheridan, WY 82801
430 Park Ave New York City, New York 10022
Midland House 2 Poole Road, Bournemouth BH2 5QY

The Superior Doctrine

Projects are a set of features or improvements broken down into milestones, and milestones are broken down into weekly sprints where one new release is pushed from a staging to a live environment.

Documentation | Level 0

This is the planning phase where we fully define & freeze features, bug fixes, improvements and set milestones and build our first sprints.

Freezing Requirements

At this beginning state we are organizing all the frozen client documentation for the specific project — use cases, user stories, features (or improvements & bugs if project is a V2 or is a takeover from an existing project from another developer) are compiled into a clear DoD and are frozen into a master document pending the approval of the prototype.

We build a full prototype encapsulating both the features and UI/UX requirements from the client side. The prototype will be the frozen master document by which developers, designers, QA, PMs and the client determine the definition of done.

This prototype with the features listed side by side on a PDF is our Single Source Of Truth. The PDF will be named with the version and will have the date created as well as the client signature at the bottom of the document to indicate the client has approved.

The PDF will be uploaded to and will be password protected.

Paving | Level 1

This is where we predict, preempt and eliminate impediments that will cost the client and Superior additional time, money and resource in the completion of the project.

Identifying Blockers

We begin this stage with PM, developer and designer meeting to identify all blockers that could arise as we progress to the finish line in the process. Included in this level is listing the client side dependencies that need to be handled immediately.

The client is notified of these items immediately pre-development so that they are aware of the issues that could hinder the successful launch of the project.

Assigning Dependencies

PM and assistants will reach out to clients to eliminate the core dependencies. Common dependencies include AWS account setups, Apple Developer accounts and content from the client.

These items will be listed, and clear direct instructions with deadlines will be provided to the clients in order that the project progresses in a reasonable manner according to schedule. The client should be notified that if dependencies are not handled in a reasonable time period the project time will elongate and there may be costs associated to a delay in progress as our team is unable to take on new projects while they are assigned to the current client’s project.

Development | Level 2

This stage is where we are in full development mode, both on frontend, backend and cloud architecture and engineering.

In this phase we work in weekly sprints, where we follow the Superior Sprint Framework:

Friday – Freeze Weekly Ice Block

This is a feature list and shall not include bugs generated by the last week’s sprint or by the client change requests. All features should be compiled into a concise list (Weekly Ice Block, WIB) to be shared with the client on Monday morning (not later than 5am client time zone).

Monday – Begin Development

Frontend, backend and cloud team work in a synchronic fashion and EoD provide a report to their PM with progression update on Features, Blockers and Bugs.

Wednesday – Internal QA

EoD Wednesday QA team accesses staging server and juxtaposes what they see with the frozen prototype. They compile concise feedback and send clear list of bugs to the team members responsible for these items with a deadline of EoD Thursday for completion.

Thursday – Internal Demo

Here the tech lead will demo via screen-share the WIB to the PM or PM assistant. If any pending items remain from the WIB the tech lead will outline a plan to achieve this goal either over the weekend or integrate into the next WIB.

Friday – Client Demo

Here the PM or assistant will demo the WIB to the client via screen-share, juxtaposing the WIB sent to the client via email on Monday AM. The client’s questions will be answered and the client will be walked through each screen highlighting the client requirements as shown on the staging environment.

If new client change requests are brought up the client will be informed that they are a new change request, and the PM will either fill out a new change request form or ask the client to fill it out. This will then be prototyped, estimated, approved by the client and tagged for V2 and placed in the Up-Sell notes for the next version. If the client cannot wait for V2 and wants this to be implemented now, client must pay in full for the change to be implemented now and must agree that the development process will be elongated and the original launch date will not be met.

Beta | Level 3

At this stage we release the beta version of the project for the client to use for 7 days. During this phase we take down all non-material change feedback and make changes and can spend a final seven days making updates for a total max period of two weeks in the Beta | Level 3.

Up-Sell | Level 4

At this point, client requests and requirements are outlined and then pitched to the client, payment is processed following a new contract or written agreement and the client card is dragged back to Documentation | Level 1 and the entire cycle continues again.

If no up-sells, new features or new items are requested, move the client progression to Launch.

Launch | Level 5

At this point, the client must have a final demo in a live environment, and the client must sign a document saying that the project is complete and the client is here asked for a testimonial, referral or other positive and profitable action like monthly maintenance.

Maintenance | Level 6

At this recurring stage, the client will be retaining Superior for monthly server, site, app or administrative maintenance.

Definitions | Reference

Use Case

The use case is a set of possible sequences of interactions between systems and users in a particular environment and related to a particular goal.

User Story

A user story is an informal, natural language description of one or more features of a software system. User stories are often written from the POV of an end user or user of a system.


A feature is a core functionality that delivers specific value and combined with other features make up the entire definition of done from a usability standpoint, not exclusive of UI/UX.


This is an enhancement from a backend or frontend perspective put into place from a client in the form of a change request.


This indicates that an error, flaw or fault in a program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.


Prototypes are interactive mockups of websites, brower, web and mobile applications designed to look and feel like the encapsulation of the frozen requirements indicated from the client at the start of the project.

Definition Of Done (DoD)

This is what we use as the final and overarching document that determines scope, completion and whether or not the client needs to process final payment and/or move into maintenance or up-sold into V2.

Any client request will be filed as a Change Request, and development team will provide clear estimate and timeline and have approval from client on all before implementing.

Change Request

A change request is a document containing a call for an adjustment of a system. It is of great importance in the change management process. A change request is declarative, i.e. it states what needs to be accomplished, but leaves out how the change should be carried out.

The development team shall not implement a change request until the prototype has been updated and approved by the client as well as the estimate and increase in budget approved by the client. The change request is an addition to or material change to the original project requirements as reflected in the DoD, Prototype and Estimate.

Dev, Stage & Live Environments


This is the developer’s local computer. Clients do not have access to this.


This is the same code pushed to a server, merged with code from other devs. Clients are demoed at this level.


This is the live server accessible to the client. Clients can access at this level.


A blocker is anything that stops or slows down the delivery of the software, or acts as a hurdle.


This is something that is required from the client side and will become necessary at a point in time before the project moves forward.


Given a version number MAJOR.MINOR.PATCH, developers will increment the following:

  1. MAJOR version is when there is complete development/design overhaul that is incompatible with the V1 software. 2.0.0 for example.
  2. MINOR version is when we add functionality in a backwards compatible manner. This means a new feature added to a current version. 2.1.0 for example.
  3. PATCH version when we implement backwards compatible bug fixes. This is when we fix a bug on a current version. 2.1.1 for example.

V2 is shorthand for the next major version and all new projects start at V1, even if a takeover project at V6, we start at V1.

For additional documentation please refer to:

Semantic Versioning 2.0.0


User experience design is the process of supporting user behavior through usability, usefulness, and desirability provided in the interaction with a product. This is front end work.

FrontEnd Developer

Front-end web development is the practice of converting data to a graphical interface, through the use of HTML, CSS, and JavaScript, so that users can view and interact with that data.


Project managers have the responsibility of the planning, procurement and execution of a project, in any undertaking that has a defined scope, defined start and a defined finish. They are typically full stack developers who manage the entire team of FrontEnd, BackEnd & Cloud Engineers.

The PM works as an interface between the client and the dev teams.

Tech Lead

Tech leads are software engineers that enable the team to work with quality and are internal facing only as opposed to the PM who works in a external facing environment as well.

Cloud Engineer

A Cloud Engineer is a technical professional responsible for duties associated with cloud computing including planning, design, management, maintenance, and support.

BackEnd Developer

Backend developers are primarily focused on how a website works. They write code that focuses on the functionality and logic powering the application they’re working on, and the technology they work on is never directly seen by users. The following nine languages are where backend developers live and breath:

  1. Java
  2. PHP
  3. .NET (C#, VB)
  4. C#
  5. VB
  6. Ruby
  7. Python
  8. SQL
  9. JavaScript


Implementation of structured user acceptance testing, prototype and demo ready staging juxtaposition to ensure success in the project delivery.


The Weekly Ice Block is a frozen set of features that are set on Friday and delivered the following Friday. These are not lists that include change requests and bugs, these are only features.