Specs Flow

Great sheet to use: Requirements Gathering Methodology

This has all of the features you should have, could have, and would be nice to have for the
different types of apps.

•
Integrations
Every feature can cover ONE functionality for customers. This includes frontend and
•
backend.

If the customer wants to integrate with a 3rd party, you need to ask them what
•
functions they want from that service provider. Every function (aka end point) will need
a separate feature.

Example:
•
You can use Twilio for multiple use cases like SMS, OTP, notifications, audio call,
•
etc.

If client says they need Twilio for OTP and push notifications, then we need to add
•
two features, as we would be consuming two API end points on from Twilio

•
Scoping Integrations
One custom feature (CF) is needed for each API endpoint
•
Most API integrations only need a single endpoint, but if you're trying to do
•
multiple, very different types of things with a single API there may be
multiple endpoints needed

One custom feature is needed for requesting permissions for each API
•
If a user needs to opt in to giving permissions for a device / app, we need a
•
feature for that (if they don't, no extra features are needed)

If data is being pulled automatically (vs on demand), an additional feature is

•
needed to manage that

Example:
•
If you want to pull health data for iOS and Android, you need:
•
Two CFs for pulling data from Google Fit (one for requesting
•
permissions; one for pulling the data)
 Two CFs for pulling data from Apple Health (one for requesting
•
permissions; one for pulling the data)

Two CFs for pulling data from each additional device/wearable (warning:
•
bluetooth connections are less reliable and harder to work with)

One feature for updating the data automatically (if desired)

•
•
Meeting Invites
If you get a meeting invite with only you and a customer as attendees, this means a
•
new customer was using Builder 360 and 'requested an expert' for help

•
Studio Tricks
Disable back button: If you accidentally click the back button from step 2 to step 1,
•
you'll lose the whole build card
Tip: Disable the swiping mechanism on your laptop's trackpad that causes Google
•
Chrome to return to the last page

•
Leading the conversation
Explain the approach of the spec call. (Features, over detailed
•
implementations/solutions)

Ask for a 2-min summary of what the customer wants to build.

•
Try to always have an artifact to look at. Customer's prototype, similar apps, or ideally
•
the buildcard in Studio. This focuses and aligns the conversation.

Raise your hand on Zoom to notify the customer you have something to say. Might be
•
less rude than interrupting them.

(With larger scopes) break things down into modules and add features to the buildcard
•
per module.

If the customer thinks cost is high, tell them we take care of brainstorming,
•
understanding your problem, suggesting how to solve it, writing detailed user stories,
designing frontend, QA, managing staging/prod environments, deploying code, etc.
They might think they can do it cheaper/faster elsewhere but they'll unlikely get all
these parts done with one party. Meaning it'll likely end up costing lots more and taking
lots longer.
 If a customer goes into lots of detail on how to solve a specific problem try something
•
like: 'We've built an app like this 20 times, so have lots of experience with it. You can
leave out the detail and just tell me the functionality you think is needed.'

•
Payment
Deposit: The deposit a customer pays for the application can be returned after the
•
customer has paid all instalments or we can use it towards the last instalment, as
desired by the customer.

Recommended Gateways (as of August 2022)

•
Razorpay is only for India-based apps
•
FYI - these are our partners
•
•

iOS App Payments: Apple takes a 30% cut of all payments made in iOS apps (drops to
•
15% if approved for the Small Business Program, or after the first year of app active in
App Store). Due to this, you must call the purchase of the good or service within the
app. Here are the features that are required:
If client needs a payment gateway → add Stripe + Apple Pay payment features
•
If has subscriptions only → add In-App Purchases payment feature
•
If client needs subscriptions + 3rd party gateway → add In-App Purchases + 3rd
•
party gateway (whatever they choose e.g. Stripe, Razorpay) payment features

There's a way to bypass this 30% commission to Apple by managing payments

•
outside the app. This is what big companies like Netflix and Spotify do. But this
requires payments to be managed on a website which requires several additional
features and the web platform to be added.

•
Build for Tablet
If a client wants their app (iOS or Android) built also for a tablet, we add custom
•
features adding 20% of the entire timeline to cover the efforts.
 Name the Custom Features: "iOS Tablet Support" and/or "Android Tablet Support".
•
•
Functionality Split between Platforms
What do you do if your customer wants some of the functionality in some of the
•
platforms but not in others? (e.g. they want a dashboard in the Web and Android
versions but not in the mobile site)
Keep it on the build card but make this clear during the design phase (tell
•
designer) and build phase (tell front end dev)

•
Types of Prototypes
What do we do for an instant (basic) prototype?
•
We use the screens from what is provided on Builder Studio. No changes are made
•
What do we do for a tailor-made prototype?
•
We only modify the existing screens from Builder Studio, change the colour, logo,
•
change icons, etc. and deliver the prototype to the customers. We do not design
screens from scratch

25 features and 1 type of user happy flow

•
1 screen per feature
•
Deliver in a week
•
Don’t need Product Roadmap nor Design phases added, just tailor-made
•
prototype phase

The tailor made prototype does not represent the design phase. It does not
•
represent an entire flow, just the "happy flow" with one screen per front end
feature (we do not design screens for back end features). I typically have no less
than 10 screens just for signup/login. You can see how this would not be enough.
we also only design up to 25 screen, and these are typically not as nice as they
would be if we invested real time in designing all the screens and flows. We
actually pull from a template and apply the customer's color scheme and logo to
"customize" it, but that is more all we do for tailor-made prototypes.

What do we do for a professional (custom) prototype?

•
All screens for the entire user flow are designed from scratch and hotspots added
•
by designer (in UIW)
 You can add the roadmap phase
•
Don’t need to add design phase; prototype replaces this phase
•
For the professional prototype, so long as the list of features does not grow past
•
the list represented in the prototype then it would replace the design phase. We
also only design front end work flows. So we would want to create a new BC for
the development in this case because the customer does not need to pay for the
design of the back end features in the prototype. I would remove all the back end
features for a prototype and then add them back in for the development stage if
they are looking to do them separately. We would not do this for projects where
we do it all in one BC.

•
Customer is Providing Designs
If a customer already has designs created, then we charge them 30% of the design
•
phase
Option 1: charge using custom features.
•
The 30% is used by us to onboard a designer who will turn all of the clients
•
designs into Sketch/Figma files, upload them into UIW and match them with
our UIE guidelines

Call the Custom Feature: UIW Conversion for Design (you'll need to figure out
•
what 30% is by adding the design phase

Option 2: manual request to add design phase at 30% of cost

•
You rely on a Manual request here, so might not be ideal. But you'll actually
•
have a design phase on the BC.

See example here: Private (https://app.clickup.com/t/10553282/PROD-32432)

•
What if they have Figma designs already?
•
They have to follow these Figma Designer Guidelines else we charge them for
•
conversion via a custom feature. The link is also available on UIW help.

We still charge 30% of design phase cost in this case

•
•
Connect to a Data Warehouse
If customer wants to connect to a data warehouse, create a custom feature to have an
•
API set up for them

•
Connect to Customer's Current Website
Do we connect to a customer's current and existing website? For instance, the customer
•
would navigate to the existing website, click on a signup / login button, get logged into
a new website we create for them, and use the new website.
This would be an SSO. The customer would need to modify the code of their
•
current website so that they log into our website upon submitting their login
credentials. We can assist the client by working out with them the SSO approach
and mechanism.

•
Builder Care & Builder Cloud
Reference docs here: https://drive.google.com/drive/folders/1k-t-dtgRh_UKuIjdj1dwXad
•
QDpDpIPgA

Can you have BCare without BCloud?

•
Yes, we can care for the code without watching over the cloud infra
•
•
Specs in Saudi Arabia
Does Azure or AWS have infrastructure regions in Saudi Arabia - No
•
Message from Utsav “currently we don't support Kingdom of Saudi Arabia and Oman
•
specifically as none of our partnered cloud providers offer a region there (AWS/ Azure/
DO) in which case you would need to take help from a local hosting provider, our
minimum requirements would be: Open Source version of Kubernetes v1.22 and above.”

Twilio as a third party should NOT be suggested to client based out of Saudi as they are
•
NOT registered in the region. Alternatives are:
https://maxmedia.com.sa/bulk-sms.php#:~:text=JawalBSMS%20Saudi%20Arabia%
•
20allows%20you,application%20to%20our%20messaging%20server.

https://www.unifonic.com/
•
https://www.jawalbsms.ws/
•
Jawal b struggles to send SMS outside the Saudi region. You might need to
•
pair it with another sms gateway to make sure you have global coverage.

•
Demo
Admin Console: You can use this site if your client wants to see a demo of the Admin
•
Console.
 https://bxabhiprojectstore949-277363-ruby.b277363.dev.eastus.az.svc.builder.cafe/
•
admin/dashboard#

•
FE Only? Customer built BE
If your customer asks for only the Front End (FE) of the application to be built by Builder
and they will take care of the Back End (BE), then double check the following points:

They must create an API for us to use and connect to their BE. Their API framework
•
must be feasible with React framework that we use for front end or vice versa

Who will be responsible for end to end testing of the app once completed?
•
Let them know that they wont be able to qualify for our Studio One subscription that is
•
packaged in cost now on our platform

Whether they want us to work on front end or back end, they need to provide us with
•
API end points OR complete designs before we kickoff else it becomes challenging to
manage the baseline scope in the first version of BC itself

•
What do we not do?
Betting, gambling, or lottery products (depends on the country)
•
What is out of scope for Builder:
•
a. We do not develop games, animations or train AI model from scratch.

b. We do not develop the apps apart from our approved tech stack which is React
Native for mobile apps, ReactJS for web apps and Ruby on rails for Backend. If
there is any exceptional case- we need to take an approval from Leaders - VP of
Delivery Paul Heathcote and SVP of Engineering - Rohan Patel.

c. We are using FIGMA tool for designing. If customer is sharing their designs in
Sketch or PSD then we need to redesign those again in Figma.

d. We do not support deployment on Google Cloud Platform with Builder Cloud.

e. We do not develop on the top of the existing customer's code.

f. If any platform is not listed on Studio then it means we are not supporting
this. Example: Tablet support for mobile apps.

•
Banking Apps
Need a FCA license first to give investment advice: This has a £50,000 fee or the client
•
can use someone else's license
 You have to be regulated if you want to give financial advice
•
To have Investments in the app, you need to add features for:
•
Holding API
•
Collecting payments
•
Need an open banking API
•
Need a feature if they are doing personal finance
•
Compliance expert needed -- add feature for this
•
•
AI Apps
Of course, we will not create or train any models ourselves, rather we will connect to a
•
service. Important things to think about when connecting to an AI service
Is the service prompt based?
•
The quality of prompts determines the quality of response. Any prompt based
•
api we want to use should come with a prompt management feature, where
admin console users would be able to edit the prompt that we send (for
example client does not like the results they are getting, they can play with
the prompt until they do. If this was not here, there would need to be code
level work done to edit the prompt (client forced to come back to builder).

Activity Log
•
Every admin console journey should have an activity log to capture every
•
prompt / piece of content that was sent to the api and the returned result /
report mapped to it

Terms and Conditions

•
Ensure that using the results how the client intends does not violate the
•
terms and conditions of the service
For example. We have a client in the US that wants to send content to an
•
AI service, and the AI service will send us back a report analyzing the
content and giving it a grade (how likely is it that the content was
created using some type of AI technology). Then the client wants to
create a data set of these inputs and outputs, and potentially sell that
data to an AI company who needs this type of data to teach their
models. This could potentially breach the ts+cs of the service provider.
So important we make sure client is aware of this and checking before
kickoff.
Have other technical questions not answered above?
Find answers from the CTE team through the channels listed on the Issues page under
"Questions for CTEs"