A course name should fit on a course tab. This seems a modest demand to make of a university website, somewhere below academic freedom and somewhere above choosing the cafeteria soup. Bryan Giger made a piece of software to help it happen. His project for St. Gallen’s Studynet removed the identifiers that crowded out course names, added colors to distinguish classes, and offered an experimental download function. A student could have worked around the interface. Giger worked on it.
There is something pleasantly unceremonious about this entry in a founder’s working life. It involves no grand unveiling. Its usefulness can be understood by anyone who has opened several nearly identical tabs and wondered which one contains the thing they need. The improvement lives in the distance between a system’s available information and a person’s ability to find it.
Giger is now the CEO and co-founder of Dashlabs.ai. Yet the smaller projects deserve a place beside the company name. They make the career legible: a programmer who also studied economics, a participant in coding competitions who returned as a judge, and a collaborator whose work extends into teaching. His public introduction on Y Combinator’s website takes six words: “I like to build stuff.”
An economist with a keyboard
Giger went to high school in Manila and worked there as a self-taught programmer before moving to Switzerland for university. His father is Swiss; his background is Swiss-Filipino. St. Gallen supplied a place to study economics and a setting in which his technical projects could meet other people’s business ambitions. The geography matters because his career belongs to both places, rather than unfolding neatly inside one national startup scene.
His F6S introduction describes an economist turned coder with an interest in automating manual processes. It is a useful description of his professional concerns, even though his interest in programming began much earlier. At twelve, a school website assignment sent him beyond the simple system provided for the task and into learning HTML and programming languages.
Economics and software meet whenever a proposed improvement has to earn its place in somebody’s day. A feature can work perfectly and still cost too much to adopt. A process can look efficient on a diagram and still require someone to copy the same information twice. Read together, Giger’s choice of subject and his declared interest in automation suggest a practical lens for understanding his work: what does the system ask people to do, and what could software take off their hands?
A secret worth sharing
In March 2017, Giger joined Björn Schmidtke, Alexander Pfyffer, and Vytautas Mikalainis at START Hack. Their SuperSecret app won first place and the Cognizant case prize. The project’s Devpost entry lists C# and Unity among its tools. Its premise was privacy at the point where a message reaches a screen - the moment when a nearby stranger can become an accidental reader.
The team combined encrypted messages, QR codes, and a recipient’s device. The intended reader could reveal the message while a bystander saw the code. It was an unusual way to think about the last few inches of a communication system. Sending information privately and displaying it privately are separate problems. A public screen can undo quite a lot of private transmission.
The code was released openly. “Everything we programmed is open source,” Giger said. That decision gave the experiment a life beyond its judging slot: other developers could inspect and change it. An award ends with a result. An open repository leaves a door ajar. For a project concerned with keeping messages secret, its workings were agreeably available for inspection.
“Everything we programmed is open source.”Bryan Giger, 2017
The useful little improvements
The Studynet project offers a closer look at how an idea becomes usable. Its instructions explain how students can run the script through browser extensions, choose colors, and match those colors to course names. It includes separate versions for the basic interface changes and the experimental download feature. The latter comes with a candid list of limitations.
That distinction is part of the work. A person installing a tool needs to know what is dependable and what still needs attention. Naming the rough edges can be more helpful than dressing them up. The documentation walks readers through the practical steps, down to preserving commas when changing the settings. There is no shame in a comma. A missing one can stop the afternoon.
Another public project, angular-sly, connects Angular with the Sly JavaScript library. Giger’s documentation describes support for horizontal and vertical scrolling, gives usage examples, and asks whether someone would like to adopt or maintain the project. It carries an MIT license. The invitation is a reminder that releasing code and keeping it useful over time are different commitments.
The tools are small enough to show their seams. That makes them revealing. A course label, a scrolling list, an installation instruction: these are the ordinary surfaces through which people experience software. They rarely appear in a company’s origin story, but they are often where a user decides whether the thing is worth keeping open.
Penguins enter the classroom
Giger’s work also appears in Penguin Academy’s early concept document, where he is listed as Tech Head alongside a team spanning development, project management, finance, and education. The program proposed coding bootcamps and an evolving learning platform. Its approach placed collaboration, debugging, research, and learning to read technical material alongside writing code.
The distinction is sensible. A beginner who can reproduce an example has learned something. A beginner who can locate an error, find a useful explanation, and work with someone else has acquired a way to keep learning. In the Academy’s proposed format, bootcamps ended with a three-day hackathon, giving participants a chance to make a product of their own.
The early document describes pilot activity in Switzerland, China, and Paraguay. It places Giger’s technical role inside an effort to make programming accessible across different settings. That is a broader task than writing a curriculum once and sending it around. Teaching tools must make room for people who arrive with different experience, different confidence, and different questions.
There is a quiet connection here with his public repositories. Instructions and examples let someone else take the next step. The teacher’s problem and the developer’s problem overlap whenever the recipient must understand enough to act independently. The code may be the object being taught; the ability to proceed is the more durable result.
The work between the work
By 2020, Giger was collaborating with Weston Lim and Philly Tan on a volunteer software project at the Philippine Red Cross. One difficulty was organizational: action items could disappear into meeting notes stored in Google Docs. The developers recommended ZenHub, which they had used before, to bring tasks and project information into a shared view.
The team connected a management repository with repositories for the actual development work. Dependencies could show when a task in one place blocked progress somewhere else. That detail is less photogenic than a finished application, but it belongs in the story. A team can contain capable people and still lose time because the next person cannot see what has changed.
Giger’s explanation of the work joined business and development concerns. In that setting, coordinating the people building the software was itself a software problem. A useful board could make responsibilities visible; a well-written task could save a conversation; a recorded dependency could prevent somebody from waiting for the wrong thing.
The larger lesson is about the effort surrounding an output. Finished products invite attention to their surfaces. Working teams need attention to their handoffs. The same appetite for clearer course tabs has an organizational counterpart: give people enough visibility to understand what comes next. The resemblance is an editorial reading of these projects, rather than a claim that Giger planned his career around a single formula.
A company, and a larger room
Dashlabs.ai was founded in 2020 and joined Y Combinator’s Winter 2021 batch. Giger’s fellow founders on the accelerator’s active-founder listing include Martin Gomez and Weston Coleman Lim. In May 2021, Giger, Gomez, Lim, and Philly Tan appeared together on Hustleshare to discuss their backgrounds, the company’s journey, and their experience entering the accelerator.
The group format suits this part of the story. A co-founder’s biography is full of other people: those who bring different skills, share the uncertain decisions, and remember the same early work from another angle. The title on a profile belongs to an individual. The company being described belongs to a collaboration.
In February 2022, Dashlabs.ai reported approximately ₱65 million raised from investors including ADB Ventures, Good News Ventures, and Immeasurable. That is a company financing milestone, with the usual practical implication: more resources to organize and more commitments to meet. It adds another kind of coordination to the programmer’s concerns.
Giger was listed on the IGNITE 2023 Young Founders Summit program with Steph Naval and Jiro Reyes, in a panel moderated by Ee Ling Lim. The audience was selected for ages fifteen to twenty. The setting gives his early learning story a pleasing return address: a founder scheduled to speak in a room intended for people near the beginning of their own working lives.
Still a reason to build
On GitHub, Giger goes by gigerbytes and lists St. Gallen as his location. His public work preserves a mixture of experiments, practical tools, and material other people can use. Taken alongside the company role, those traces offer a more particular portrait than the word entrepreneur can manage on its own.
The appeal of this career is its scale of attention. An unreadable label is small. A shared project board is larger. A company requires a larger room again. Each asks someone to notice where understanding or action gets stuck. Reading Giger’s projects this way leaves room for the differences between them, without pretending that every experiment was a rehearsal for the next.
There is also room for the plain pleasure of making something. The six-word introduction has no ceremonial weight to it. It could sit comfortably above a weekend project or beside a company listing. For Bryan Giger, both belong in the picture: the organization that needs managing, and the ordinary reason to open an editor and see whether a thing can work a little better.