Before you begin.
Some useful guidance.

Start with a specific task: finding information, drafting a reply or processing a document. The first discussion examines the expected result, available data and how to judge usefulness. This may lead to conventional automation or improving an existing application.

A document assistant can connect to selected sources to help find information or prepare answers. The project must specify usable documents, updates, permissions and how sources are presented. Answers still need review according to their use and the consequences of an error.

No. It is more useful to explain your objective and constraints. Model or service selection comes afterwards, considering context, required capabilities and conditions of use. You can also tell us which tools you have already tried.

Options depend on the applications, interfaces and available permissions. We clarify what can be read or changed, when and with which approval. An initial version can prepare suggestions before direct actions in a business application are considered.

We propose representative situations and criteria related to the need: accuracy, missing information, sources, format and ease of review. These help compare results and identify limits. Human approval and handling insufficient answers are discussed within the project’s context.

Yes. Web and mobile development are among the studio’s areas of expertise. A portal, internal tool or customer journey may meet the need without AI. Choices start from users, required features and possible links to existing tools.

An initial assessment establishes its structure, documentation and available access. We can then discuss the intended change, dependencies and checks needed before changing behaviour. Feasibility and scope follow that assessment.

Sources are chosen according to the task and users’ responsibilities. Scoping defines necessary information, read or write permissions and approvals. Connecting a tool does not mean opening every document to every account.

These choices depend on the need and environment. We examine where information is processed, services called, configuration options and access conditions. Selected choices and their constraints should be explained for the project concerned.

It is useful to clarify the delivered scope, documentation, operational access and people who will maintain it. Deployment, handover and any maintenance or support arrangements are agreed together. The first discussion can identify your team’s needs in these areas.

Describe the current work, the people involved and what you want to improve. Generic examples, tools used and known constraints are usually enough. You do not need to send a sensitive file or have a complete specification already written.

They depend on the journeys to build, connections, data preparation and required approvals. Scoping distinguishes a useful first step from possible later changes. The proposal is discussed against that scope rather than an unclear list of features.

An initial discussion may identify a desired deadline, but the schedule depends on scope, access and decisions. Stages and approval points are clarified when these are sufficiently understood. Tell us important dates and participant availability from the outset.

Work can be organised around remote discussions, demonstrations and approvals. When being onsite helps clarify the project, a meeting can also be discussed. The format depends on the need, participants and arrangements agreed with the team.

Stages can include demonstrations and feedback on representative situations. Identify the people using the product, approving decisions and understanding technical constraints. The frequency of discussions and approval criteria are defined in the project arrangements.

The introductory workshop does not require programming experience. Other workshops start from everyday uses and the team’s context. The group’s experience is discussed during preparation to adapt vocabulary, examples and exercises.

The programme can be adjusted around familiar situations: writing, summarising, organising a request or examining what information to share. Examples must be usable under the agreed conditions. Fictional or simplified cases often avoid sharing confidential documents.

The workshops shown are proposals to prepare with you. Duration, participant numbers, location or video call, tools and any materials are agreed when you contact us. Explain the group’s experience, objectives and practical constraints so we can define a suitable format.

A workshop helps people understand, try and clarify uses. A software connection or operational automation needs its own technical scope: data, permissions, actions and monitoring. If that need emerges, it can be scoped separately with the studio.

By phone: Monday to Friday, 10 am to 10 pm, Paris time. Saturday and Sunday: email only at contact@stellarrstudio.com. Visits to the studio are by appointment.

The studio is based at 163 rue du Canal, 27500 Pont-Audemer, Normandy, France. Contact the team before travelling to agree a meeting and its format. You can also describe your need remotely on the contact page.

Stellarr Studio publishes Moon AI, presented as a workspace bringing several AI models together. The studio also supports integration, development and data architecture projects. A custom need is discussed in its context and does not automatically require Moon AI.

The blog publishes guides on artificial intelligence, data protection and project delivery, as well as studio news. An RSS feed lets you follow published articles. The contact page is also available for feedback or questions you would like us to address.