Socle

Today was all about building and training the LLM behind Socle Intelligence, probably one of the most ambitious parts of Socle so far.

The goal isn’t to make another AI chatbot that spits out generic advice. I’m building a system that can actually understand what’s happening inside a business by connecting customer experiences, employee performance, feedback patterns, and historical data.

For example, if a customer says their food took forever but their server was amazing, the model needs to recognize two completely different signals: a potential operational issue and an employee who deserves recognition.I’ve been working on the model’s reasoning, training it to interpret feedback in context, experimenting with different parameters, and building the infrastructure that will eventually let business owners ask questions about their own data.

The hardest part is getting the AI to distinguish between an isolated complaint and an actual emerging pattern, without making conclusions that the evidence doesn’t support.

I’m also exploring local model deployment rather than relying entirely on external AI APIs, which adds another layer of complexity.

The end goal is simple: turn thousands of individual interactions into intelligence that businesses can actually act on.Still plenty of work left, but this is where Socle starts moving beyond collecting data and toward understanding it.

spent most of this session working on one of the bigger systems behind socle: the analytics/intelligence engine.

the goal is basically to make sure socle does more than just collect feedback and throw a bunch of charts at a business. if someone scans a Snap, leaves feedback, recognizes an employee, saves a place, visits somewhere, or interacts with socle in another way, that creates a signal. the harder part is figuring out what those signals actually mean when you start connecting them together.

so i started building out the system that takes those interactions and turns them into actual insights and suggestions.

for example, instead of just saying “service mentions went down,” socle should be able to notice the pattern, look at what guests are actually saying, which types of guests are experiencing it, whether it is happening repeatedly or is just an outlier, and then suggest what the business could actually do about it.

i also spent a lot of time on the explanation side of it. i really don’t want the dashboard to randomly spit out recommendations with no idea where they came from. every insight needs to have evidence behind it, so businesses can see why socle thinks something is happening, what signals contributed to it, and how confident the system is.

if it gets something wrong, they should also be able to report that so we can keep improving the logic.the engine connects things like written feedback, selected responses, recognitions, interaction history, guest taste/context, repeated patterns, and changes over time. when multiple signals point toward the same thing, the system can treat that differently from one random interaction instead of pretending every piece of data means the same amount.

i also worked on how this splits between the business and employee dashboards. managers need broader operational suggestions and patterns across the business, while an employee should get useful feedback about what they are doing well and what they could improve without just getting a weird analytics graph thrown at them.a big rule while building this has been no fake intelligence.

if there is not enough evidence to make a useful conclusion yet, socle should say that instead of inventing one. right now a lot of the engine is deterministic/rules-based so i can actually test why every result appears. later i want to add an AI layer on top so businesses can ask questions directly and the system can reason across all of this context, but i want the underlying data and evidence system to be solid first.this is probably one of the first updates where the two sides of socle really start connecting together.

the guest-facing product creates the interactions, Snap gives us another real-world interaction point, and the intelligence engine turns all of that into something a business can actually use.still a lot to build and test, but this is starting to feel a lot less like “analytics” and a lot more like the intelligence layer i originally wanted socle to become.

spent around 11 hours on socle today, which is definitely over the devlog limit because i completely forgot to log before getting locked in 😭

this was one of those sessions where i fixed one tiny thing, noticed three more things that felt off, fixed those, then somehow found even more. i went through a bunch of screens and flows trying to look at everything like someone using socle for the first time instead of someone who already knows where every button is. i cleaned up spacing, navigation, loading states, interactions, weird edge cases, and a lot of smaller details that were not huge on their own but made parts of the app feel unfinished.

there was not one massive new feature this time, but the app feels much more solid now. i think we are getting to the point where the remaining work is mostly about removing those little moments of friction that make a product feel rough, even if users cannot always explain exactly why.

we were also hoping to ship this version, but we ran into some repo issues, so we are trying to figure out a cleaner solution before releasing it. hopefully we can sort that out soon and get this version out.

spent around 9 hours going through socle and just fixing anything that still felt annoying, confusing, inconsistent, or unfinished.

at this point a lot of the bigger stuff is already built, so i focused more on how everything actually feels to use. i went through different screens, flows, buttons, navigation, loading states, and smaller interactions and changed a bunch of things that were still kind of rough.

a lot of the changes were pretty small by themselves, but together they made the app feel way smoother. i’m trying to get socle to the point where you don’t really have to think about the ui at all because everything just works how you expect it to.

i also tried looking at everything more like a new user instead of the person who built it, which helped me catch a lot of stuff i was probably just used to seeing before.

next i’m gonna keep cleaning up anything that still feels off, but i also want to start moving more time back into bigger features and systems again. then… SHIP IT!!

spent around 8 hours working mostly on the taste system and making it easier to actually test.

the biggest thing i changed was visit system. since we don’t have the full location tracking system built yet, i replaced the old visit flow with a simple button for now. now we can actually test how visits affect someone’s taste without waiting for the full tracking system to be done.

i also changed some of the math behind taste, mostly how different actions are weighted and how repeated activity is counted so one place can’t mess up someone’s entire profile.

the screenshot below isn’t the exact equation or exact part i changed. i’m trying to be careful with how much of the scoring system i show. if you look at it and have no idea what’s going on, that’s kinda on purpose. i don’t want people to be able to reverse engineer it later or find ways to manipulate it if there are any loopholes we haven’t caught yet.

next, i’m gonna keep testing the weights, keep doing ui/ux and qol polishes, and just keep fixing anything that still feels off before we bring in more testers.

spent around 9 hours doing another huge UI/UX polish pass on socle.

at this point most of the main stuff is already there, so now i’m mainly finding all the smaller things that make the app feel unfinished. stuff like weird spacing, inconsistent layouts, interactions that feel a little off, small bugs, or certain parts of the app just not feeling as polished as everything else.

for most of this session i was basically just going through the app over and over and fixing anything that felt wrong. cleaned up a bunch of layouts, fixed smaller UI/UX issues, changed some interactions, and reworked parts of the app that still felt kind of rough.

i also added more locations and more content to existing locations so there’s actually more to explore when people start testing. that’s becoming more important now because as we bring in more testers, i don’t want them opening the app and running out of stuff to do after like 5 minutes.

didn’t really add one massive new feature this time, but the app feels way better than it did before this session.

everything is starting to feel a lot more complete now and we’re getting way closer to being ready for a much bigger testing wave.

spent around 6 hours doing a big UI/UX cleanup across socle.

i went through a bunch of different screens and just fixed a lot of the smaller things that felt off. stuff like weird spacing, layout issues, awkward interactions, inconsistent components, and parts of the app that still felt a little unfinished.

i also cleaned up some of the navigation and made things easier to understand, especially for people using socle for the first time. most of the changes were pretty small on their own, but together they made the app feel way more polished and consistent.

the main goal was just getting everything into a much cleaner and more stable state before we bring in a bigger wave of testers. i’d rather fix all the obvious stuff now so when people test it, their feedback is actually about the product and not random issues we already knew were there.

this update was mainly focused on UI and UX. i used codex to help with some of the code implementation while i went through different parts of the app and tested everything.

while testing, i found a few bugs in one of the features i had already built, so i went back and fixed those too. after the changes, the feature was working properly again and the overall experience felt a lot cleaner.

next, i want to keep going through the app and completely get rid of any broken UI, bad UX, or annoying little issues. the goal is basically to get the QoL as close to perfect as possible before more people start testing it.