Brain-computer interfaces: where consumer BCI apps stand

By Marco Lopes · March 25, 2024 · Design, 3D & XR

Brain-computer interfaces are moving from research headlines into product conversations. We are seeing affordable EEG hardware, developer toolkits, and growing interest in combining neural signals with AI and immersive environments. But a headset that measures electrical activity is not automatically a practical replacement for a mouse, controller, or touchscreen.

At Kordspace, we approach BCI as a multidisciplinary design problem: hardware quality, signal processing, software architecture, and user expectations all have to work together. As a remote collaborative studio working across software, AI, Web3, hardware, and design, we are interested in what teams can build responsibly, not just what makes an impressive demo.

Here is where we think consumer BCI apps stand today, and how we would approach a first product.

What we mean by a consumer BCI

A brain-computer interface uses measured brain activity as an input to a computing system. For consumer applications, that usually means non-invasive electroencephalography, or EEG: electrodes placed against the scalp detect small voltage differences associated with electrical activity.

We distinguish that from several technologies commonly grouped into the same conversation. Eye tracking measures gaze. Electromyography, or EMG, measures muscle activity. Heart-rate sensors and skin-conductance sensors provide physiological information. These can support excellent interactions, but they are not direct measurements of brain activity.

This distinction matters when we describe a product. If a headset detects a jaw clench through muscle artifacts, we should call it a muscle-based interaction rather than imply that we have decoded a thought.

We also separate consumer EEG from implanted interfaces. Their signal characteristics, medical requirements, risks, and intended users are fundamentally different.

The March 2024 reality check

Neuralink's first human implantation, announced in January, and its March demonstration of a participant controlling a computer cursor have brought implanted BCI into mainstream discussion. We see this as an important development, but not evidence that implant-based consumer apps are ready for ordinary retail distribution.

Implanted systems remain a clinical and research undertaking. We should not translate a demonstration involving a person with paralysis into a near-term promise of effortless thought control for everyone.

For teams building consumer-facing prototypes now, the more accessible route is external sensing. Platforms such as OpenBCI, Muse, and EMOTIV offer different hardware and software approaches, although access to raw signals, SDKs, commercial licensing, and supported integrations varies.

Our first procurement task would be to verify those details. A comfortable consumer headset may not expose the data a prototype needs, while a flexible research-oriented board may require substantial work on enclosure design, electrode placement, and onboarding.

What today's apps can realistically do

We see the strongest near-term opportunities in constrained experiences rather than general-purpose thought decoding.

Biofeedback and guided experiences. We can use EEG-derived features to influence sound, visuals, or a guided session. The interface should explain that the feedback reflects a noisy measurement and an interpretation, not an authoritative reading of someone's mind.

Simple selections under controlled conditions. Research-established approaches such as steady-state visually evoked potentials and P300 responses can support selection interfaces. They depend on structured stimuli and suitable processing, not unrestricted internal commands. Visual stimulation also introduces comfort, accessibility, and safety considerations.

Exploratory games and interactive art. A slow-changing signal can modify an environment, influence a soundtrack, or create an additional gameplay layer. We can design these experiences so imperfect classification remains understandable rather than punitive.

Assistive interaction research. BCI may provide valuable access for some people with severe motor impairments. We would pursue this with relevant users and specialist partners, rather than assume a consumer wellness headset can deliver a dependable assistive product.

Where the hype gets ahead of the signal

Scalp EEG is difficult to work with. Eye movements, facial muscles, poor electrode contact, electrical interference, and head motion can all affect recordings. Hair, headset placement, and differences between people complicate setup and repeatability.

Labels such as “focus,” “calm,” and “engagement” deserve particular caution. We may calculate features that correlate with a state in a particular protocol, but that does not make the output a universal psychological measurement. A score that looks precise can still have uncertain meaning.

We would therefore avoid claims that a product can reliably read private thoughts, diagnose attention problems, or measure productivity from a consumer headset. We would also resist presenting neurofeedback as a guaranteed route to better concentration or mental health; evidence depends on the protocol, population, and outcome.

Our practical rule is simple: describe the signal, the interpretation, and the limitation separately. Users should never need a neuroscience background to understand what the app is claiming.

Designing BCI for 3D and XR

XR is an attractive place to experiment because we already have spatial interfaces, embodied interaction, and responsive environments. It is also a demanding setting: users move, facial muscles activate, and another head-mounted device can create fit problems.

We would not begin by replacing every controller action with EEG. We would begin with one optional input channel that complements gaze, hand tracking, voice, or a physical control.

For example, we might let a deliberately paced biofeedback signal alter an ambient 3D scene while conventional inputs handle navigation. Alternatively, we could test a constrained selection method where a user confirms an option, with a clear cancellation route.

The mapping should match the signal's behavior. Slow, uncertain estimates suit gradual environmental changes better than jumping between menu items. Destructive actions should require an independent confirmation rather than rely on a classifier alone.

We would also test the combined hardware early. Electrode contact, cable routing, headset pressure, cleaning, and accessibility can invalidate an otherwise elegant interaction concept.

Treat calibration as part of the product

Calibration is not a technical inconvenience we can hide behind a loading spinner. It is part of the user's experience and a major contributor to whether they return.

We would provide a short, understandable setup flow showing device connection, contact quality where available, and whether enough usable signal is arriving. We would explain why the app requests a particular action without suggesting that unsuccessful calibration is the user's fault.

During use, we need visible uncertainty. If signal quality falls, the interface can pause the BCI feature, hold a neutral state, or offer conventional controls. It should not confidently animate a supposedly meaningful score from unusable data.

We would also test across separate sessions. A model that works immediately after calibration may behave differently after the headset is removed and replaced. Everyday reliability matters more than one successful recording.

Where AI helps, and where it does not

Machine learning can support artifact detection, feature extraction, and classification. It can also help adapt a model to an individual when we have appropriate training data and a valid evaluation method.

But AI cannot manufacture reliable information that the sensor did not capture. We would start with a simple baseline and establish whether a more complex model improves performance under realistic conditions.

Evaluation needs particular care. Randomly splitting nearby windows from the same recording can produce an overly optimistic result. We would separate sessions, and people, when claiming generalization, to test the performance the product actually needs.

We would also record non-neural explanations. If a classifier succeeds because users repeatedly blink during one task, we have not demonstrated the intended brain-based interaction. Comparing against artifact channels and controlled alternatives helps us avoid building a product around the wrong signal.

A practical software and cloud architecture

We would keep device acquisition and time-sensitive feedback close to the user. A local application or companion process can handle the vendor SDK, timestamps, buffering, and basic signal-quality checks. Depending on hardware support, communication might use Bluetooth, USB, or a network connection.

For a Unity or Unreal prototype, we would isolate the acquisition layer from the scene logic. The experience should consume a small, documented stream of events or estimates rather than depend directly on a particular headset's packet format.

When cloud services add value, Google Cloud is our preferred starting point. Cloud Run can host application APIs, Cloud Storage can hold consented recordings, and Pub/Sub can support asynchronous processing. AWS or Azure can serve the same architectural roles when project requirements favor them.

We would not send raw EEG to the cloud by default. Local processing can reduce exposure and network dependence. Cloud use should follow a specific need, such as an explicitly consented research workflow, rather than become an automatic telemetry habit.

Privacy is a design requirement

Neural recordings and their derived profiles deserve careful treatment. Even when a consumer device cannot reveal arbitrary thoughts, its data may still support sensitive inferences or become identifying in a broader dataset.

We would explain what is collected, what we infer, where processing occurs, who can access it, and when it is deleted. Consent for operating the app should be separated from optional data reuse for model development.

Our defaults would include data minimization, limited retention, encryption, least-privilege access, and usable deletion controls. Derived scores are not automatically harmless or anonymous simply because raw EEG has been discarded.

For workplace applications, we would be especially cautious about coercion and monitoring. We would not design an individual “attention leaderboard” as a routine analytics feature.

Our Web3 work does not change that position: raw neural recordings and sensitive profiles do not belong on a public blockchain. Immutability conflicts directly with many sensible deletion and privacy expectations.

How we would scope a first prototype

We would begin with one user group, one environment, and one measurable interaction. “Change an ambient scene using a calibrated EEG feature while seated” is a testable scope. “Control the metaverse with your mind” is not.

Before adding BCI, we would build the same experience with an ordinary input. That gives us a baseline for usefulness, completion time, comfort, and user preference.

Our evaluation would include setup effort, failed calibrations, false activations, missed commands, fatigue, and repeat-session behavior, not just classifier accuracy. We would agree on stopping criteria before testing so enthusiasm does not turn every disappointing result into a reason to add complexity.

A short launch-readiness checklist

• Can we explain the input without overstating what the device measures?
• Have we verified SDK access, licensing, and hardware availability?
• Does the interaction remain safe when the signal is wrong or missing?
• Have we tested headset fit, motion, and repeat sessions?
• Can users decline optional uploads and delete stored data?
• Have we checked accessibility, stimulation risks, and relevant regulatory obligations?
• Does BCI add value compared with a simpler input?

Build around a real benefit

As of March 2024, we see consumer BCI as a promising but constrained interaction technology. The opportunity is not to claim that every app needs a neural interface. It is to find situations where a carefully bounded signal creates meaningful feedback, access, or expression, and to be honest when another input works better.

If we can help turn a BCI, AI, hardware, or immersive-design idea into a grounded prototype, start a project with us. To explore how we bring the disciplines together, read our related services pages.