This is Chris and Robert from HeyCharge (https://heycharge.io/). We're developing low-cost EV charging for indoor environments like underground parking garages.

Current indoor EV chargers are expensive to buy, install, and operate, especially because they need internet connections and cloud-based backends. They're also unreliable, because even if the charger's internet connection works, the user might not have one on their mobile device while underground.

Our chargers don’t require an internet connection, they don’t require any setup other than an electrician to wire power, and our charger and app work together, even when underground and outside of mobile network coverage. This makes them cheaper and more reliable.

We exchange cryptographically-signed, single-use tokens between the charger and our mobile app. We provide tokens proactively to users whenever they have mobile network coverage, meaning they have a supply to use when underground in front of their charger. The charger doesn't need to connect to the internet, only to the user's phone. It provides a charging session in return for a token. After charging, a token is sent in the reverse direction, where it’s eventually sent to the back end. We only provide a replacement token to the user in return for them bringing a complete charge session report. The user’s app and device is an untrusted intermediary in this design, making the system resistant to abuse.

I (Chris) got my career start at UC Davis working on EVs in a graduate research group under the inventor of the modern plug-in hybrid, Dr. Andy Frank, followed by experience at Google, Mercedes-Benz R&D, and E.ON Energy. I finally brought my first plug-in car home to a Munich city-center apartment in late 2017 and realized just how difficult and expensive installing EV chargers in these buildings was. We started HeyCharge to bring EV charging to users like me, living in apartment buildings. We are deploying hardware to our first pilot sites now. Looking forward to your thoughts, questions, and comments!

The idea of using tokens is very clever and I can see how that could really reduce the complexity of getting a charger implemented. I'm curious about the overall business model here, do the sites hosting the chargers make money from this or is it more like an amenity?

Thanks! :) We're really excited about how our token system results in a nearly "plug and play" charger -- just add power!

We have two models:

In a few markets, we operate a "full service" model where we're invited in by a building owner to install infrastructure at our cost, and charge a subscription fee to users to access it in addition to charging for energy consumed. Building owners love this because it's a natural way to transfer costs for the infrastructure to tenants, and -- as "full service" implies -- it takes all the administrative overhead of managing the infrastructure, billing tenants for power, etc. off their plate.

We also offer our technology as a platform for other companies to use as a part of their product or service. With a combination of our SDK and API, they can enable their own app to access HeyCharge devices. This means we can offer the low cost of hardware, low cost and high scalability of setup, and low operating costs to their product/service. We're piloting this with several energy utilities, mobility operators, and a few more that I can't talk about yet. In this case, we operate on a hardware sales + SaaS model.

EV charging in shared use / multi-family housing is still one of the harder areas to solve. So great to see more options coming - I wish you the best of luck.

One side is also regulatory. At least where I was because the building feed was not up to code, and to get charging in would hit meters, the upgrade costs were too high. Hopefully solutions can show up there as well. Love not having to have network connectivity just local.

We aren't able to fix every wiring or capacity issue in every building, but we have a neat combination of low-power hardware options and load management. The net effect is that often our infrastructure will work where other options struggle. And thank you for the kind wordsa

> We only provide a replacement token to the user in return for them bringing a complete charge session report.

What prevents the user from reusing the token? Does the charger keep some state about previously seen tokens?

Exactly. This is something we can do because we operate semi-private (as opposed to public) infrastructure, and over its lifetime each charger will see a (relatively) small number of users.

I see. Then the expectation is that the user charges only at one charger, as otherwise a token might be reused at a different charger. Thanks, sounds interesting!

More or less. We expect our users to charge at a relatively small number of chargers (you might have, say, 10 shared chargers in some buildings), and likewise for chargers to see a relative small number of users over their lifetime. Hope you'll get a chance to use it in a building near you soon!

If you want to create a user-friendly experience, how about making it so that I just plug my car in and it charges?

No phones, no apps, no access cards. The charger recognizes my car, the car has the billing info, done.

Sigh.

It was such a massive ball drop when the plug standard insisted on having the plug + car detection of the plug being inserted work in all conditions, but then failed to account for the simple fact that billing also needs to be solved.

It's like they thought of it as someone inserting a gas nozzle, or that the electricity would be free.

And now we've rolled out how many of these?

We agree. :)

So far, only Tesla really supports this at scale (and unfortunately it's proprietary so we can't really use it).

However, the coming wave of EVs will finally support ISO15118, which is a global standard that brings this experience to any EV. We'll support it as soon as there's a meaningful population of vehicles out there with the car-side support. Come to our labs in a month or two for a preview ;)

I love the idea! Cannot wait to have one here, as the the few charging stations are in the center of the small village where I live, so always have to park there, and pick up the charged car later...

Exactly the problem we want to solve!

Why not just use a laundry card type system? Seems like a solution looking for a problem.

Replacing the RFID card is just one (small) benefit of our approach. The bigger ones are:

1. Eliminating the internet connection lowers both installation cost and setup complexity for the charger. The RFID card doesn't save you from having to take these (expensive) steps when setting up a site, and to pay for the connection on an ongoing basis.

2. Once you eliminate the external variable of configuring a charger to use an internet connection and a backend, the setup flow becomes virtually a plug and play. This substantially improves scalability as we don't have to train dedicated installers. Any electrician who can read a wiring diagram can bring up a site. And, of course, this translates into lower costs for the user.

Of course you could have a disconnected charger using statically-configured RFID cars that doesn't require #1 and #2 above, but then you can't bill people for what they consume or centrally manage access. This is OK for some small sites, but isn't really a scalable solution.

Great idea. Good Luck!

Hi Chris and Robert. I'm the cofounder of Smartcar.com. We're an API for EVs. We're backed by a16z and NEA. (I also went to UC Davis too!)

I'm excited about what you folks are doing and would love to connect. We've been helping many companies in this space better integrate with electric cars.

Can you shoot me an email? sahas@smartcar.com

Will certainly drop you a line! Thanks for reaching out!

Hi there! We are Orestis and Urs from Zeit Medical (https://www.zeitmedical.com). We enable fast stroke detection at home.

90% of strokes go untreated due to stroke recognition delays. Many patients live in fear that a stroke might happen and go unnoticed for hours, particularly if they are asleep when it starts. Stroke is currently impossible to detect based on symptoms. Unlike a heart attack, there is no distinct pain. There is a compelling need for a monitoring/alert system that will enable fast access to treatment.

Orestis has a PhD in Biotechnology and Bioengineering and has spent a decade developing wearable health-monitoring technologies. Urs is a pediatric critical care physician. Both founders have done research at Stanford. We've also both experienced the never-ending fear of another stroke in our families. We decided to do something about this problem--only 10% receiving treatment is just not cutting it!

We have a stroke detection algorithm which has been clinically proven in operating rooms. We're pairing it with commercially available brainwave sensors to create a smart headband that enables immediate stroke detection at home. The sensor pairs with our app and if a stroke is detected it alerts caregivers abs 911. This is different from other technologies that aim to improve patient transportation (once the patient is in the ambulance) or door to needle time (once the patient is in the hospital). The longest delays occur prior to calling 911, so this is the critical phase for making a difference.

The headband pairs with an app to analyze the brain’s electrical activity in real time with our stroke-detection algorithms. Brain activity metrics are already used in the clinical environment, but so far this know-how has remained siloed within the hospital. Our headband runs on AI that emulates the ability of expert neurophysiologists in digesting brain activity information to infer whether a cerebral injury is taking place.

We have recently kicked off a 15 person human factors study to assess overall system adoption and compliance. We also offer a sign up to get it first once our technology is cleared by the FDA. We look forward to your questions and comments!

Looks amazing!

Your website also mentions seizures. Are you trying to get FDA clearance for both?

Also, why did you choose the subscription route?

Very interesting!

Is there some data on the 'optimal' time from when a stroke starts where intervention would prevent serious impairment? i.e. if you detect a stroke, how many minutes/hours do you have before irreversible damage is caused?

Relatedly, what measures are done when a stroke is detected to minimize damage/impairment?

Also, what's your false positive rate?

Wish you all the best of luck! I've had family members who've had strokes and early detection might have helped them a ton.

Thank you for the insightful comments and questions!

1) There is a ton of interesting research on the topic of what happens from the onset of the stroke until permanent lesion formation.

In brief, there is usually a stroke "core" where the damage starts within seconds to minutes.

However there is a big volume surrounding the core, usually referred to as "penumbra" that is of substantial size and remains "live" longer due to access to collateral blood flow. This practically means that the small arteries which run in parallel to the main one that was blocked (causing the stroke) can sustain the surrounding tissue for a longer period of time than the core. However this blood flow is not enough to sustain those tissues in perpetuity and as a result the penumbra will also "die" if no treatment is provided promptly to re-establish flow in the "main" artery.

So there is a real race to save the penumbra!! (https://en.wikipedia.org/wiki/Penumbra_(medicine))

Summarizing the above -> Time=Brain.

The most important point to keep in mind is that for treatment to be provided there must be something "left" to save upon arrival at the hospital. This is usually not the case when people get strokes during sleep or when they are alone (it's hard to detect so there is a ton of delays pre-911)

2) The management of a stroke depends on the stroke type, location, severity, symptoms. For ischemic strokes (85% of all strokes) the strategy is to bring the patient as quickly to the hospital, complete imaging diagnosis and re-establish blood flow in the affected vessel (via thrombolysis or thrombectomy)

These options are really well explained here: https://www.nhs.uk/conditions/stroke/treatment/

3) We are optimizing our tools for zero false positives. Final product requirements will be set in communication with the FDA.

4) If you think that you family members might be interested in our technology, ping them to check out our website.

Is there anyway to put this technology on my wrist on into a t-shirt, or even implant? I like the idea I have higher risk factors for stroke, but I'm not too keen on wearing a headband nightly.

Thank you for the comment!

We have a vision to make future versions of our technology that will be even more inconspicuous. We also have IP on implantable versions of this. For people that live with stroke risk, our current form factor is the first step towards providing some peace of mind :)

I know nothing about strokes and who's at risk. Perhaps the website could be improved in that regard because, after reading it, I have no idea if I should buy it for myself or family.

Thank you for pointing this out. We are working on a "educate yourself about stroke" page that we will add in our website.

In the meantime: There are some great resources at

1) cdc : https://www.cdc.gov/stroke/facts.htm 2) aha :https://www.stroke.org/

This is a valuable product and will help lots of people. I am interested in becoming a distributor/reseller in my country. I sent an email to you guys.

Congrats on your launch. Question, if the device is suggesting the user may be developing a stroke - what do they do? Do they go to the ER and show the docs that there’s abnormal electrical activity so imaging of the brain must be done? Without physical symptoms, I’m not sure most ERs would be prepared to deal with this…or would they? Or is it assumed symptoms would develop by the time the patient arrives to the ER?

1) Our algos are designed to detect brain activity patterns that are associated with the onset of stroke. Detection of these patterns will send an alert to the individual, their caregivers, and 911 (can opt out).

2) The patient will present to the ED, via medical transport or in special circumstances private transport. We will perform informative sessions with the EDs that lie within our initial rollout area. The EDs will know what to expect and will perform imaging on patients arriving with our alert. Going forward, the individual will also have information on their app they will be able to show the physician, to inform them with data about our tech.

3) Most commonly symptoms develop within minutes, after the neurons are no longer receiving oxygen. In an ideal scenario treatment could be provided in the patient’s home right after the alert, but before this can happen the tech will need to have gone through additional confirmation. We are currently relying on confirmation of the stroke in the ED with the current gold standard: CT perfusion or MRI.

Super neat…

- How common are strokes generally?

Seems like a lot to wear this all the time — but also I’m not familiar with the risk factor.

- How much quicker is this at detecting a stroke versus someone simply observing it happening with a naked eye?

Like how much time does this save over simply seeing physical symptoms with your naked eye or feeling the symptoms for yourself? 1 second, 1 hour, 5 hours, days?

Hi WORMS_EAT_WORMS

Great questions!

1) For the US-> There are approximately 1 million strokes every year. Stroke is the #1 cause of disability

2) Good point. We are starting with a system that can be work at night time + whenever the users feel most vulnerable. There are many patients who who through periods of increased risk (i.e. after a 1st stroke, after a transient ischemic attack).

3)Stroke recognition is one of the biggest pain points in bringing stroke victims to treatment. Strokes that happen during sleep (commonly referred to also as wake up strokes) are practically impossible to detect based on symptoms. There is not pain associated with it (like in a heart attack).

4) We have heard crazy stories from patients and caregivers about how different their outcome would have been had they been alerted a couple of hours earlier. Our vision is to help everyone go to the hospital in under 1h. Our first target is to enable everyone to go to the hospital within 4h which is currently the time window for tpa d (clot busting medication). What's the current status? -> only 4% nationwide get tpa because they arrive too late.

If you know when the stroke started and its more than 5h past that -> no tpa.

If you don't know when the stroke started -> no tpa.

This looks fantastic! I’d love to know what are the signals and models you’re using to detect strokes? (any papers you could link to would be awesome) And what’s the accuracy like?

Also, are you thinking you’ll try and sell into hospitals or purely D2C?

Thank you for the comment !!

We cannot share our models but we are using brain wave analysis to detect stroke. Our algorithm is currently tuned for maximal specificity and might be tuned differently for inpatient and outpatient use. We are in conversation with several EEG vendors for inpatient use of our algorithms.

Best of luck to Orestis & co, they have been investigating this domain for many years and they are in a great position to find the product-market fit.

Thank you!

Could this be used outside of the US? Like in Mexico

Would it be useful for someone who had small lacunar strokes which provoked parkinson?

Thanks, awesome company

Thank you for your comments!

1) Currently focusing on clearing the FDA in the US. One of our clinical advisors is very passionate about helping bring this also to Mexico. Please sign up in our waitlist and we will make sure to keep you posted.

2) You are raising a very good point about lacunar strokes. In general these are deeper in the brain structures and not easily picked by cortical-level brain activity monitoring. However we feel confident that once our product is regulatory cleared and out there collecting data, we will be able to pick the finer effects caused by such strokes.

Would love it if you could detect hemorrhagic vs ischemic so people at risk could keep tPA at home!

How do outcomes for stroke patients vary based on treatment?

Time to treatment is the most important factor in defining stroke treatment outcomes. Stroke outcomes are quantified at 90d post event with a metric called Modified Rankin Scale. The treatment strategy is defined based on the type, location, and severity. The two options we have for ischemic strokes (i.e.85% of all strokes) are TPA (clotbusting medication) and thrombectomy (catheter based mechanical removal of the clot). Each of the them has its advantages and disadvantages but the common denominator is that the earlier the patient arrives in the hospital, the more efficacious they are.

I think you should further synthesize and emphasize these facts in your marketing - otherwise, the impact and importance of your work isn't apparent to laypeople.

Thank you for this insight. Communicating accurately the value is a very important aspect in what we are building.

We are the founders of Kodex (https://www.kodex.us). Kodex makes it easy for companies to process and respond to subpoenas from governments around the world.

Government agencies subpoena user data from thousands of companies around the world, and companies largely rely on email, fax, and spreadsheets to manage them. At a previous job, we would frequently see companies struggle to comply with legal orders, because they lacked the internal resources or expertise to automate the process of working with government agencies. Even multi-billion dollar companies had this problem. At scale, it is enormously burdensome.

Somewhat surprisingly, companies have all independently learned to comply with these requests in almost the exact same way. Regular ticketing systems don't work for this, so companies have adopted a web of Zendesk tickets, spreadsheets, and emails just to manage the intake of requests. To respond to requests, they typically send unsecured emails. The fact that this inefficient and insecure setup is so common suggests that these companies' needs can be met with one product, rather than custom solutions for each company.

Kodex automates the entire process of parsing, analyzing, and responding to subpoenas by providing companies with their own online Government Request Portal. It is similar to the Law Enforcement Portal that Facebook made for themselves, but it is a resource for every other company to use.

I think most people who haven't lived this problem assume it is only an issue for big tech, when in reality big tech are the only ones who can afford to build their own internal tools to alleviate their pain. If any of you have felt this pain, we'd love to speak with you! And your comments and questions are welcome.

I think this is really great. Do you have a public transparency report feature on the roadmap?

We do already offer company specific transparency reports, so they can analyze the threats on their platform and the agencies investigating them! We have also been thinking more generically about offering a public transparency report that doesn't give away any customer specific details.

Love to know your thoughts!

Congrats on the launch.

What's the hardest thing you have found getting Kodex to this point?

How many government bodies are you connected to? Can you use your platform even if they do not use it?

Do you use a subscription pricing model?

Great questions! The hardest part was probably getting our initial customer. This is inherently sensitive company info, and getting the initial social proof & trust from a big name opened a lot of doors for others to trust us.

We have about 60 agencies verified with us so far. What's interesting about this problem is that the company dictates how government agencies contact them. As a result, the moment our customers adopt Kodex, they automatically pull in any government agency that wants to contact them. We have new government agents signing up everyday to send our customers requests.

We do use an annual subscription pricing model.

Happy to connect offline!

> As a result, the moment our customers adopt Kodex, they automatically pull in any government agency that wants to contact them.

Am I reading this right: agencies aren't reaching out to companies because it's kinda hard to because every company has their own process? Or at least, agencies are slowed down by this fact? So, couldn't adopting your product be seen as a bad thing? If a company prefers noncompliance to government agencies (legal noncompliance through explainable bureaucratic friction), and the lack of a product like yours allows for friction to slow down both the government sending, and companies responding to, for example FBI requests, that sounds like an ideal state for some companies.

Say for example if I manage a wiki, forum, library etc for protest movements, I would be motivated to make it as hard as possible for the FBI to investigate some of my users that the FBI has improperly identified with the unjust "Black Identity Extremist" [1] label. I mean, obviously I wouldn't become a customer of yours, but if other companies also don't become your customer, the FBI has less resources writ large to deal with my organization manually. Therefore, in general, it's helpful for everyone to avoid helping the FBI do their job more easily, right?

[1] https://www.aclu.org/issues/racial-justice/protectblackdisse...

Thanks for the comment!

I see what you're saying, but I think there is a fundamental misunderstanding - Kodex was made to make things easy for the company, not the government. Agencies are never deterred from reaching out to companies because it's "kinda hard," nor because it's different for each company. It actually doesn't even slow them down - data requests are already growing ~25% YOY. Govt agencies get more and more resources to serve subpoenas, but companies are left to fend for themselves with an ever increasing volume. The moment a company receives a subpoena, the company is now legally obligated to respond in one way or another. The nuance is that you don't necessarily have to comply and provide data - the company can push back on the legality of subpoena, but it will still need to be addressed one way or another.

Sure, you can certainly choose noncompliance through bureaucratic friction but that doesn't eliminate your problem as a company, that actually only makes it more burdensome for your company. At some point you still have to address the subpoena.

When a company does not have an intake method for these types of legal inquiries, it only makes it harder on the company...not the agency. The agency will just send the inquiry to any publicly known address, email, etc. In one way or another, if they want to send you a subpoena, they will...aka making the process hard does not prevent them from reaching out to your company, it only makes it hard on your company.

I think a perfect example is Facebook. They built their own Law Enforcement Portal because 1. there was nothing like Kodex that they could buy, and 2. They understood that making the process easier for themselves greatly helped their company with cost of compliance, protecting user privacy, and pushing back on overly broad requests. Did the Facebook LE Portal make it easier for agencies to send them subpoenas? Sure. But it's not as if agencies wouldn't still be sending just as many subpoenas to Facebook if they hadn't built their LE portal...Facebook would still be getting them, it would just be that much harder for Facebook to manage them.

In regards to your example, I understand wanting to do your part to stand up to government overreach. The government is not infallible - they've been on the wrong side of history more than once.

I think the answer to standing up for these issues, is not to create more friction, but instead to facilitate a streamlined process of engaging with government agencies - so you (as a company) can more easily push back on the legality of a subpoena that you don't agree with, and also more easily assist in the very real instances of identifying victims, or subjects, that end up saving a life.

I think this subpoena process has become so sloppy and overwhelming that it is easy to forget that there are victims at the end of this transaction.

If there are subpoenas sent to you regarding a user on your wiki, wouldn't you want to have a clear understanding of what the government is looking at, and why? What threats are on your wiki? Wouldn't you want to easily be able to prioritize a case involving child exploitation, or self-harm, and help protect those users, while also having a better avenue to push back on requests you find to be unjust?

There is a lot that can be fixed in government. This process is one of them. The goal is not to "help the government do their job more easily"... making the process easier for the company, forces the government to do their job BETTER, and helps society move forward.

A relief to receive a response like this, thank you for taking the time to write it up! Sometimes I feel like the technology sector moves quickly without taking the time to consider the ethical implications of developing technology, and it seems to me that you have taken that time and have a good ethical basis for your business.

Best of luck!

> the company dictates how government agencies contact them

What mechanism governs this? Are you standing in as their registered agent? Politely asking agencies to follow your process and finding that they tend to be willing to do so? Something else?

Companies provide points of contact for these types of legal process to be served on them - it is akin to the registered agent process. Govt agencies do not have the authority to dictate how a company accepts this legal process, only that they comply with the legal order itself. As a result, govt agencies follow the methods of contact that a company provides, whether its a fax number, email address, mailing address, etc.

Agencies are willing to follow the process that a company lays out because it makes engaging with that company easier. It is not in an agency's interest to make the process difficult (i.e. demanding to use fax machines when a company already has a lawenforcment@company.com email set up).

How big is the market? It seems people who really need this and see it frequently have the resources to build their own and its otherwise rare enough to not be worth a whole product.

I'm glad you brought that up!

I think that is the most common misconception with this problem, and that is why it has gone so long without a solution. You are correct in that the biggest players (i.e. big tech) are the ones who have the resources to solve their own problems. However, this problem spreads much further and wider than just big tech. There are thousands of companies in the US alone that get these requests (from ISPs, banks, insurance, fintechs, crypto, tech, etc.). "Big tech" typically gets all the focus because of the volume they get (FB gets 300k+ per year). What goes unnoticed is that even at 100+, or 1000+ per year, these requests are very overwhelming for companies to manage. These are also the companies that don't have the internal resources to fix their pain like FB and Google.

To answer your question about the market, there are ~30k companies that are vulnerable to data requests in the US alone. At $100k price point, that is roughly a $3B market

love this! needed this at the last company I worked out. Was always surprised how manual and generally not secure the whole process seemed to me.

Thanks! So surprising how hard it is for companies to handle these requests. Love to learn more about your experience with it!

keeping this company in my library of saas's to use.

Great way of looking at it - good to have on deck even if you haven't yet gotten a data request, because you never know when the "flood gates" might open and bog your company down.

Hi HN—we’re Harkunwar, Vipanchi, Chaithanya and Mehul from Oneistox (https://oneistox.in/). Oneistox offers online cohort-based courses for designers, architects and engineers to advance their professional growth.

Online learning by watching pre-recorded videos does not work for design and architecture. Learning design is an iterative process that happens through communication over drawings, sketches, screen visuals and physical prototypes. It also depends greatly on being exposed to how your peers are addressing the same problem and understanding approaches from the experienced. No LMS (Learning Management system) in the world caters to this way of communicating while learning. There is also very little quality curated content online on design, architecture and construction subjects, and no space which upskills you in these fields sufficiently for career growth. Meanwhile, demand for designers has been growing at 21% annually over the last 5 years but only 1/5th of this demand has been met.

We felt the skill gap when we were in grad school. What we were being taught was last revised 35 years ago. 80% was also by the faculty that was non-practicing in architecture—hadn’t built anything in their life. Institutes were doing nothing to address this in India. We researched deeper by talking to professionals abroad, and found that this problem came out to be global, especially in developing and under-developed nations.

We've built a new, cohort-based, project-based LMS specifically to learn design subjects for feedback over drawings, sketches, screen visuals and physical prototypes. Our learners work in groups of 2-6 on live projects and create concept designs to executable drawings from scratch. Project-based learning and peer-to-peer interaction in cohorts increases completion rates by 12x! So far we've had over 2000 learners from 27 countries upgrading their skills in subjects like Building Information Design, UI/UX, Sustainable design, Computational design, and others. We connect course graduates to industry professionals for hiring. We look forward to your feedback!

I think the instant chat/support icon on your website is confusing because it is the same as the WhatsApp logo. I initially thought it must be something like "share to WhatsApp". Consider changing it to also be more fitting to the overall design of your website :)

This is awesome!

Probably wouldn't sign up for a course at the moment, as I am focusing on honing BE and FE software engineering skills at the moment, but definitely will bookmark just in case the stars align. (meaing when I have time and see a live course that I like. As a side note, it would be a cool feature to see some upcoming courses on your site too).

Best of luck on this though! Really want to see something like this succeed.

Thanks! :D We are launching 6 new courses in the coming quarter. 2 of them are around digital product design and UI/UX that you might be interested. We believe and see trends where future is going to be about every individual having some learning about design principles in their subjects.

How do you pronounce your name?

Based on their logo it looks like: "one is to x"

On point - Its /wan-iz-tu-ex/ - referring to scale like 1:100, 1:500, 1:5 etc. In design, especially tangible design subjects like industrial design and architecture, everything is prototyped at some scale or proportions that is friendly to understand the design development.

If you have already considered this enough, disregard my comment..This name really trips me up as a german reader. If you like that it‘s a bit out there, that’s cool. If you want most people to read it like you just explained, you might need to capitalize the individual words.

Edit: just saw your logo. That reads well on first glance.

Looks like https://onetox.com/ is available. Maybe they can get big and buy it.

Hey HN, I’m Etai, together with Andrew a co-founder of Secoda (https://www.secoda.co). Secoda is a collaborative workspace for data teams that makes it easy to share metadata, queries, charts and documentation with any employee.

Companies store a growing amount of knowledge in BI tools, data warehouses, data pipelines, queries and documentation. Because these tools are not connected, it has become more difficult to manage all of this. Even with great practices, organizations still struggle to get value out of their data - up to 73% of all enterprise data goes unused. One of the big contributors to this problem is that organizations create data silos by not documenting and centralizing their data knowledge in a single place where every employee can access information about data.

Today, most data teams end up documenting all this data with Google Sheets or Confluence, which get outdated quickly. Because data documentation is outdated and hard to find, employees struggle to discover, understand and use it. This overwhelms data teams with repetitive questions about how to use and where to find company data.

In our last roles, Andrew and I had a hard time understanding context around different data resources. It was difficult to understand which table to use, what dashboard to trust, who to talk to about a particular metric or why we changed our pricing model. All of this data knowledge was in our data teams head and it made it really difficult to try to work with data. It would take around 2 weeks to get an answer to any data request because the data team was so backed up with questions. This sucked.

Secoda is unique because it's focused on helping the data team curate knowledge for the less technical employee. Data teams can use the tool to curate knowledge for specific departments or roles so that only the right people are able to see the data knowledge that they should see. We currently integrate into data warehouses, BI tools, dbt as well as Airflow and once teams connect their data to Secoda, they can get a comprehensive view of all their data knowledge in one place.

We’d love to hear your feedback or experience with the problem that we're solving and would be thrilled if you would sign up at https://secoda.co to let us know what you think!

This addresses key usability issues with most data initiatives. Don’t be dismayed that people who haven’t tried to share reports with teams don’t get it… I get it and I presume end users will love it. There is a particular need for metadata support in Google data studio that would be great if you could help solve: there are no folders or any real way to curate data outside of report sharing and leaving text boxes on the reports themselves. It’s kind of a nightmare for an otherwise powerful and popular tool.

I’d also like to see comment threads over data discoveries. Like a snapshot of a report with in-context exploration would be super helpful. In my experience the default behavior is a report screenshot dropped into a slack thread, and I know there can be better. QlikView does a decent job at this but it has the trappings of enterprise software. I think that would unlock a lot of value out of reports and give a place for teams to understand opportunities and celebrate wins. Congrats on the launch!

Thanks for the positive message. We appreciate the support from people who understand the problem that we're trying to solve with Secoda. We haven't had someone request Google Data Studio as an integration, but if you were interested in discussing what that would look like please reach out to andrew@secoda.co. It looks like there's an API for accessing assets in Google Data Studio, so it's definitely possible.

Our most requested feature is discussion threads attached to each data resource (table, dashboard, etc) to build context around a resource. So that will be coming in the near future, and we are happy to hear you also think it would be super helpful!

Long term, do you see yourselves in the MDM space [0]? Informally, I think of MDM as "enterprise into analytics", and my first impression of Secoda is "analytics out to enterprise". Schemas and data dictionaries seem central to both. An MDM solution like Tamr looks a lot heavier weight than I think the experience you target.

[0] https://www.gartner.com/en/information-technology/glossary/m...

You've hit the nail on the head here. Long term we want to bridge the gap between the data team and rest of the organization through a central repository of data knowledge. Using MDM's terms the data team = IT, the rest of the organization = business, and repository of data knowledge = master data. So it's almost a one-to-one comparison, and we've never heard of MDM so this is great! We are also trying to make the experience lightweight and user friendly so that everyone is interested in exploring their company's data.

You mention data lineage on your pricing page, but do you have any examples of what that looks like? Can you support custom lineages driven by an api?

An example of what lineage would look like is the following: You have source tables A and B that are joined to create a model C and then C is used in dashboard D. We are able to infer the lineage A->C->D and B->C->D.

We extract lineage in a couple of different ways. The main way is by parsing SQL queries in your data warehouse to determine which tables and dashboards are upstream/downstream. The other way we extract lineage information provided directly from dbt and BigQuery who have nice APIs for this information.

We are working releasing an API in Q4 that supports pushing information from say an Airflow DAG to Secoda to give us more lineage context. Hopefully this answers your questions.

This looks really cool, but not being able to self-host without an enterprise plan is a deal breaker for us :( We use Metabase right now not because we like it but because we can host it on our own servers, with our own firewalls, behind our own Cloudflare Access rules, etc etc. Understand why you might have chosen to go this route, though. Best of luck!

Fair enough! If that changes let us know

Very cool. How much of this working effectively depends on a properly deployed dbt project?

Hi there, I'm the CTO of Secoda so happy to answer your question. Our dbt integration works with dbt cloud, and are working on making it compatible with dbt core as well. What we'll pull from dbt via their API is the metadata associated with the models, docs, and, jobs. We have a free version of the platform, so you can sign up and test it out if you'd like to see what that information looks like in Secoda.

This looks really interesting. How does it differ from something like Amundsen : https://github.com/amundsen-io/amundsen

The catalog portion of the Secoda product is similar to Amundsen, but we also have a Data Dictionary for defining metrics, Analysis Documents for queries and charts, and Requests for handling data questions. We take these different pieces of functionality and make everything interconnected, so that it's one unified repository for your data knowledge.

Additionally, we try and make Secoda easy to use for both technical and non-technical users, whereas a tool like Amundsen is more focused on the technical user.

How does it compare to traditional reporting tools. Lot of modern day BI tools like looker for instance, do have features like this. Where do you position yours company as compared to traditional tools?

The main way that Secoda differs from a traditional reporting tool is that we offer a more complete view into the data knowledge/context of an organization. A traditional reporting tool like Looker does great for reports, but it misses context about how certain models are created, where data is coming from downstream, and more general knowledge that is stored inside of a wiki. Secoda takes all of the context across a data stack and puts it in one central place. So we actually see ourselves as complementary to these reporting tools as we are a layer on top of them.

This is my very naive opinion, having context of the data or report, I would perceive it as nice to have.

I would love to see some case studies or customers who attest that this actually created primary value which is kind of missing. Just an opinion.

How does the tagging feature work? Is it at the table and column level?

You can add tags to any data resource in Secoda (table, column, dashboard, dictionary term, etc). When you tag resources, you can search for them by tag. Our customers have found it very useful for keeping everything organized.

Such an important problem - I really hope you become the new standard for companies' data. The number of times I've seen complex, undocumented queries...

Thanks, we hope so too! At Secoda, we really want to make data less intimidating for anyone in the organization to explore and use. When the whole company can use data to help inform their decisions it really does make a big difference.

Take my money!

Now to assign someone to give it a whirl and hope it works.

Thanks so much!

We're happy to help you or whoever would set it up and show you how other teams have been using the tool. Feel free to shot me an email at etai@secoda.co if you'd like any help along the way

Will do. Just saw that API access is gated to enterprise accounts so we may need your help.

We have pre-built integrations with many popular data tools (Snowflake, dbt, Tableau, etc.) that can be setup in less than 5 minutes. If those don't fit your needs then we can definitely setup some time to discuss the API.

Hey everyone! We’re Juliana and Robert, co-founders of Parallel Bio. We're improving drug discovery by replacing animal models, in the hope of making cures for humans, not mice.

The biggest reason why 92% of new drugs fail is that drugs are currently discovered in mice, which are not realistic models of human disease but are used due to the challenges of working in humans. We've created a human ‘immune system in a dish’ to discover drugs more likely to work in patients.

Robert has a PhD in immunology and is intimately familiar with the ways in which people are failing to recognize the importance of the immune system in diseases and the failures of trying to model it adequately. Juliana has a MSc in bioengineering and for the last 5 years has been working on developing mini-organ models in an effort to more accurately model human disease.

Both of us have always recognized a gap in the pharmaceutical industry that everyone seems to acknowledge exists, but few people are working to fill, which is using humans and human systems to treat disease. Since it is not always possible to test drugs directly in patients, there is a critical need for human systems to test drugs on that will predict downstream success in the patient.

Our immune organoid is a 3D system that has all of the features of a human secondary lymphoid organ. It contains all of the cells (B cells, T cells, NK cells, etc), structures (germinal centers, LZ/DZ, etc), and function (somatic hypermutation, antibody and cellular response, etc) that you would expect to see in a secondary lymphoid organ. It matches the genetic background of the patient from which it’s derived, meaning it also models diseases that patients have. And because it exhibits the same functions as a human immune system, you can test drugs and vaccines as if you were testing them in actual patients from the start. It's also easier to work with than mice.

People are currently using our platform as a new way to produce antibody therapies, to test vaccine candidates, and to test new treatments for diseases like multiple sclerosis.

Very cool and promising. Is there any literature on this "immune system in a dish", or is it ,understandably, proprietary?

Three main Q:

* How's reception been with med chemists?

* How do you expect cost to compare with some of the individual existing immunological wet lab screens? No individual numbers, just comparative would be interesting to know.

* How granular is data collection for this kinda all-in-one system, and is throughput high enough to collect data and build predictive models alongside it?

I used to work in the earlier stages of drug discovery and advances in these assays are fascinating. Really exciting work, guys!

There are some reviews on immune organoids that I posted below. This is the first human one though able to recapitulate these features at a commercial scale.

We haven't gotten any feedback from med chemists yet! The cost is comparable to other in vitro systems and is cheaper than using animals. *The data collection can be very granular. You can use single cell techniques like flow and RNA-seq to generate high resolution data. You can also use high resolution imaging techniques like CODEX. Moving into high throughput and building predictive models is exactly where we want to go. Currently, we can generate 7500 organoids from a single donor and screen them in the thousands. We're working on building a ML pipeline along with automation so that we can screen in the hundreds of thousands if not more. Key to this though is that we have designed a platform that is amenable to this kind of automation and scale.

Oh wow, your upcoming plans sound great. Keep up the good work guys!

And I highly recommend reaching out to a med chemist for some input. There's a lot of veteran retirees specializing in spaces adjacent to this who are open to consulting here and there. They're generally quite kind.

Thank you! If you have a good recommendation, we'd love an introduction. Please let me know at robert at parallel.bio.

On behalf of all the mice, thank you very much for doing this. I'm all for modern medicine but the number of mice, primates and other mammals that we kill in the name of science every year does not sit right with me.

I’ve always felt that if there was _any_ morally acceptable reason to harm and kill animals it is for the sake of (reasonable) medical research. In principle the ethics board is there to make sure this is true but in practice they rarely do anything about it. Perhaps the real way to solve that problem is hold the IrBs to a higher standard and make them do their job?

I always try to reverse a situation to see if it makes sense, and then I ask myself: what would we think if aliens came to earth to experiment on us with untested medicine, kill us afterwards and only when it is perfectly safe on us they would apply it to themselves. I believe a large fraction of humanity would say that that is unethical and they'd have all kinds of cognitive dissonance to deal with (and associated reasons why this is different) to explain why what we do is ok.

I personally don't think it is ok, but it apparently is a necessity, at the same time if this can be stopped then that would be great.

We feel exactly the same way. Not only is it unacceptable that over 110 million animals a year are sacrificed for research, but these models do a terrible job of translating to humans and in most cases cannot even model the disease of interest but are used regardless. I used to work in tuberculosis where mice are predominantly used even though they do not get the disease and the disease they do get has the exact opposite pathology as a human.

If it's ok with you I will point some investors in your direction that are doing deals in this space.

Please do, and I appreciate the introductions! My email is robert at parallel.bio.

I've sent you an email, we'll take it from there.

We agree that this would be an important step. That being said, there is a paucity of models that would make suitable replacements to animal models. People are working on this issue, but many more people need to be working on developing better in vitro systems. Even with our platform, animal models still have to be used for certain assays (e.g. ADME) but we hope that one day this will not be the case.

Amazing and very cool! A couple of questions, if you can share at this time, since this resonates with my interests.

- Which patient/donor cell type are these immune organoids derived from?

- Are the organoids made with induced pluripotent stem cell technology?

- What is part of the workup post treatment, e.g. histology, NGS? If NGS, what kind (WGS, WES, RNASeq) and technologies (Illumina, PacBio, ONT)?

- Are you looking for mutations from the drug and vaccine treatment (e.g. comet assay, Duplex-Seq)?

Thanks for the feedback! I'm happy to share more.

- They're derived from secondary lymphoid tissue. We're trying to biobank as broadly as we can to capture sex, age, race, HLA, genetics, and other characteristics in a wide net.

- These are not iPSC-derived organoids.

- This depends on the readout but workup post treatment so far has included histology, immunofluorescence, serology (ELISA, SPR, etc.), CyTOF and other flow, broad RNA-seq, bulk and single cell repertoire sequencing for B and T cells, and MSD/Luminex.

- We haven't looked for mutations from drug and vaccine treatment. We'd love to know more about what you're thinking there.

This is a moonshot if I ever saw one. Exciting stuff.

Does your system also have epithelial lining, with all of the components of innate immunity which integrate with the adaptive immune system?

The role of the nervous system is more and more recognized as being integrated within the immune system - is there any way you can somehow include that in your system as well in the future?

Exciting to hear this! Do you have any references to the type of work (if your own isn’t published) that closely resembles the organoid models you use?

How finicky are these organoids to maintain? It used to be true that organoids are harder to maintain than super large mouse colonies by a long shot!

What validation are you doing on your immune organoid to confirm they work correctly for the assay you’re trying to do?

How do you emulate the various ailments in these organoids? You mentioned MS, are you able to emulate MS like conditions (or even EAE) in these systems?

There's been a lot of research around organoids but our human platform is unique. Here are two reviews discussing organoids that have been so far for the immune system, though these have almost all been done in mice (https://pubmed.ncbi.nlm.nih.gov/31853049/; https://pubmed.ncbi.nlm.nih.gov/32112908/).

The organoids are incredibly finicky until you figure out a culture system they like. Then it is actually very easy to maintain them. This allows us defensibility as it's hard for others to figure out but easier for us now that we have.

We've used the organoid to test 12 immunomodulators and confirmed they matched human clinical data. We also vaccinated the organoids against 8 infectious diseases and they produced a full immune response with class switching, germinal center formation, somatic hypermutation, etc. We're also in the process of using more historical controls to show that immune reactions that were missed in mice and other animals are captured in our system (e.g. there are highly inflammatory drugs that were safe in mice but deadly in people once they got to clinical trials).

By biobanking on diverse patient backgrounds, diseases are emulated in these organoids naturally. Immune disease is typically a function of dysfunctional cells that exist in a patient. By capturing an immune niche that has those cells, we have the disease-causing cells. We can confirm they emulate a disease by demonstrating a phenotype on a tissue of interest (e.g. we can make an MS immune organoid from a patient with MS and then show that the immune cells from the organoid demyelinate neurons). This should be the same for any immune disease as we continue to generate proof of concept.

Heads up I went to email you a congratulatory email at hello@parallel.bio but my email was rejected. Might want to double check your google groups settings.

Thanks for the heads up. We're looking into it, but in the meantime robert at parallel.bio or founders at are both good email addresses.

Why is your website empty?

We're in the process of launching and are working on coming out of stealth as fast as we can. It shouldn't be empty in the near future!