Question 1

Can we talk to you before the requirements are settled?

Accepted Answer

Yes. You don't need a finished specification. Engineers take part from the enquiry stage, and we work through the business goal, the people who will use it, and the problems on the ground together. From there we narrow down what to verify first and which features are actually needed.

Question 2

Can you start by untangling work we currently do in spreadsheets and by hand?

Accepted Answer

Yes. We look at the current workflow, the spreadsheets, and how existing tools are used, then work out where systematising it would pay off. We think in terms of reducing effort and mistakes for the people doing the work, not in terms of building software for its own sake.

Question 3

Will you build exactly the features we ask for?

Accepted Answer

Not necessarily. Where a request doesn't fit the goal or the cost-benefit, we'll say so and suggest either not building it or a smaller way to test the idea first. Limited budget and time should go into features that produce results.

Question 4

Can we see a prototype of the screens before development?

Accepted Answer

Where it helps, we produce a prototype showing the screens and the flow so you can review them. Aligning before implementation avoids large rework. Depending on what you're trying to learn, we sometimes favour a rough mock over a polished design.

Question 5

Can feedback from the people using it feed back into development?

Accepted Answer

Yes. We collect what comes out of user testing, proofs of concept, and real use, and fold it into what we improve next. We don't add every request — we prioritise based on business impact and how often something is used.

Question 6

Will the engineer we talk to also work on the build?

Accepted Answer

As a rule, the engineers who will implement it take part directly from the enquiry and requirements stage. We don't run a process where a salesperson takes the requirements and hands them to development later. If the team does need to change, we share the roles and the handover plan in advance.

Question 7

Do we need in-house technical expertise?

Accepted Answer

No technical expertise is required. What we need is someone who can tell us about the business and the work, and help decide priorities with us. We'll agree a meeting rhythm and time commitment that's realistic for where the project is.

Question 8

Can the team change shape partway through a project?

Accepted Answer

Yes. An MVP validates demand with a small team, and the full build adds designers, engineers, and QA as needed. Rather than fixing a large team up front, we adjust it in the phases where it produces results.

Question 9

How do day-to-day communication and regular meetings work?

Accepted Answer

We use whatever fits your tooling and the project — Slack, Teams, or something else. Day-to-day questions happen directly in text, and regular meetings cover progress, decisions we need from you, and what's next. Frequency is set to suit the situation.

Question 10

What happens if a team member has to be replaced?

Accepted Answer

Source code, issue tracking, design decisions, and what was agreed in meetings are shared across the team, so knowledge never lives with a single person. Where a change is necessary, we build in a handover period to limit the impact on the project.

Question 11

How are the monthly fee and contract term decided?

Accepted Answer

They follow from the roles needed, the team size, the amount of work, and the length of the engagement. We confirm the goal and your budget in the first conversation, and set out the monthly fee, the term, and what's covered before any contract. Specific terms are agreed per project.

Question 12

Can we prioritise features to stay within a budget ceiling?

Accepted Answer

Yes. We list out everything you want, then prioritise against business impact, urgency, and development cost. We work out what fits inside this month's ceiling and what waits, and choose an approach together that doesn't overrun the budget.

Question 13

Can we add engineers for a limited period?

Accepted Answer

Yes. The team can be expanded for periods where the workload rises, such as a full build or a large feature addition. We tell you the roles, the cost, and the lead time to get them started as soon as the plan is clear.

Question 14

Is there a charge for the first conversation or an estimate?

Accepted Answer

The first conversation is free. We hear where you are and work out whether ALBY Studio can help and what approach fits. If paid investigation or validation is needed before a contract, we explain the scope and the cost in advance.

Question 15

How long does it take from first conversation to launch?

Accepted Answer

It depends on the scope and how you want to validate. After the discovery session we narrow down what the first release needs to prove, and propose a team and an approximate timeline. Our default is a plan that ships something small and learns from it, rather than waiting for a big finish.

Question 16

How are source code and intellectual property handled?

Accepted Answer

How source code, deliverables, and any existing libraries are treated is made explicit before the contract, based on the project. We confirm together what needs to be shared and who holds what rights, so that future operations or bringing the work in-house isn't obstructed.

Question 17

Can features and priorities change mid-development?

Accepted Answer

Yes. Because it's a monthly-retainer team, priorities can be reshuffled around user response and the state of the business. We lay out the impact of the change and agree the next scope before it goes into development.

Question 18

What decides which features make it into the MVP?

Accepted Answer

It isn't simply about having fewer features. We narrow to the minimum needed to confirm that there's demand and that the business hypothesis holds. Anything not directly serving that validation — including polish — waits, so you get real user response sooner.

Question 19

Can you handle generative AI, and integration with our existing systems?

Accepted Answer

Yes. For generative AI and RAG we check accuracy, running cost, and how data is handled, and can start from a small validation. For integration with existing databases, business systems, and external SaaS, we investigate the interfaces and terms of use before proceeding.

Question 20

How do you choose which technologies to use?

Accepted Answer

Not by what's fashionable. We weigh the features required, development speed, who will operate it, how easy it will be to change later, and running cost. We explain why we've chosen something and what risks we're assuming, and propose a setup your organisation can realistically live with.

Question 21

Can you design and build the cloud infrastructure too?

Accepted Answer

Yes. We design as much of the infrastructure as the system needs — AWS or Google Cloud architecture, permissions, monitoring, backups, and deployment. We account for future traffic growth and operational load while starting from a setup that isn't over-engineered.

Question 22

How is code quality managed?

Accepted Answer

We combine code review by multiple people, automated tests, static analysis, and continuous build checks, in the mix that suits the project. The goal isn't only that it works today, but that it can still be changed safely after launch.

Question 23

Will you take generative AI accuracy and running cost into account?

Accepted Answer

Yes. We define the accuracy the process actually requires and check responses against an evaluation dataset. We look at mechanisms to reduce wrong answers, usage limits, and using different models for different jobs, to balance accuracy against API cost.

Question 24

Can we keep working with the same team on operations and improvement after launch?

Accepted Answer

Yes. The team that understands the context and the decisions made during the build continues after launch, handling incidents, improvements, and new features. If the volume of development settles down, we can discuss a team shape suited to an operations phase.

Question 25

Can you take over and maintain a system another company built?

Accepted Answer

Yes. We start by surveying the source code, infrastructure, documentation, and how it's currently run, and setting out what is known and where the risks are. Once it's in a state where it can be changed safely, we take over maintenance and further work.

Question 26

What's the setup if there's an outage or a defect?

Accepted Answer

We ask how critical the system is and how quickly it must be addressed, then agree the monitoring approach, the escalation path, and the scope of first-line response in advance. Where you need specific service hours or target response times, we set those individually alongside the maintenance scope.

Question 27

Can we move to a smaller team after launch?

Accepted Answer

Yes. Once the volume of development settles, we revisit the team against the maintenance and improvement actually needed. We keep the people who hold the knowledge while adjusting the cost and the way of working to suit an operations phase.

Question 28

Will you look at post-launch usage data and propose improvements?

Accepted Answer

Yes. We work through what the available data shows — access logs, how the product is used, the enquiries coming in — and identify the problems. We don't read numbers in isolation: proposals come from the data together with your business goals and what users tell you.

Question 29

Can you support bringing development in-house later, or handing over to our own engineers?

Accepted Answer

Yes. We share the code and the design, put documentation in order, join reviews, and walk through the development process, so the work can be moved to your team in stages. After the handover we can continue supporting only the parts you want us to.

Question 30

Can we discuss security and the handling of confidential data?

Accepted Answer

Yes. We confirm what data is involved and what level of assurance is required, then design the controls needed — access restrictions, encryption, log management, environment separation. Where generative AI is used, we also check how input data is handled and each service's training-use settings before choosing one.

Question 31

Can you make sure data we send to generative AI isn't used to train the model?

Accepted Answer

We check each AI service's contract terms, data retention, and training-use settings, and choose services and connection methods that meet your requirements. We also consider designs that never send confidential information, or that transform it down to only what's needed.

Question 32

Can we discuss personal data protection and industry-specific guidelines?

Accepted Answer

Yes. We confirm the data, the users, and the industry requirements involved, then set out the technical controls and operating rules needed. Where legal judgement or third-party certification is required, we work with specialists and with the relevant department on your side.

Question 33

Are source code and design documents shared with us during development?

Accepted Answer

Yes. Source code, issues, and the significant design decisions are managed in a form you can review. Which repositories and documents are shared, and how accounts are managed, is decided to fit your environment and security requirements.

ALBY Studio FAQs

Enquiries & shaping requirements

How the team works

Cost & contracts

Development & technology

After launch

Security & data

Discuss your project
and budget with us

Enquiries & shaping requirements

QCan we talk to you before the requirements are settled?

QCan you start by untangling work we currently do in spreadsheets and by hand?

QWill you build exactly the features we ask for?

QCan we see a prototype of the screens before development?

QCan feedback from the people using it feed back into development?

How the team works

QWill the engineer we talk to also work on the build?

QDo we need in-house technical expertise?

QCan the team change shape partway through a project?

QHow do day-to-day communication and regular meetings work?

QWhat happens if a team member has to be replaced?

Cost & contracts

QHow are the monthly fee and contract term decided?

QCan we prioritise features to stay within a budget ceiling?

QCan we add engineers for a limited period?

QIs there a charge for the first conversation or an estimate?

QHow long does it take from first conversation to launch?

QHow are source code and intellectual property handled?

Development & technology

QCan features and priorities change mid-development?

QWhat decides which features make it into the MVP?

QCan you handle generative AI, and integration with our existing systems?

QHow do you choose which technologies to use?

QCan you design and build the cloud infrastructure too?

QHow is code quality managed?

QWill you take generative AI accuracy and running cost into account?

After launch

QCan we keep working with the same team on operations and improvement after launch?

QCan you take over and maintain a system another company built?

QWhat's the setup if there's an outage or a defect?

QCan we move to a smaller team after launch?

QWill you look at post-launch usage data and propose improvements?

QCan you support bringing development in-house later, or handing over to our own engineers?

Security & data

QCan we discuss security and the handling of confidential data?

QCan you make sure data we send to generative AI isn't used to train the model?

QCan we discuss personal data protection and industry-specific guidelines?

QAre source code and design documents shared with us during development?

Discuss your projectand budget with us

Discuss your project
and budget with us