speedypro

This process was a huge learning curve and I thank everyone for their input, from the start of this thread. Since I got more feedback, I've decided to take a step back with Tuicamp. It's the "lots of hardware" needed that got me to rethink my approach. Who has the time to manually record hundreds of students at meal time? Who has time to manually add/update the menu list? All this information has led me to rethink. I will be adding some APIs at some point but Tuicamp may remodel to be something else. Maybe I'll look at offering this service to schools where they would own the software etc.

There are significant changes to the website, made over the school term (last week). New Meal and one-off order pages Display meal images Display one-off item images Add meals with dates it's available (Commences tab) User registration* *For registration, I've limit registration to a uk school email address to reduce the noise. If you are keen to not use the demo and would like to invite someone (as test parent/carer), you can but only if you register. The demo account would not be able to send emails which means who you've invited wont be able to use the system. If you would like to register, but not use a school email address, send me a PM of the email address you'd like to use. Please note you must have access to this email address as you'll need to confirm the email address. I believe by "letting you in", I could get things done much faster with the help of your feedback. Should you register, invite someone which they would become a parent. From there you could simulate what happens when that parent adds a child, top-ups etc. Have another look at the demo account to see what's new.

One-off payments section is changing to look more like an e-commerce. Same like an e-commerce, a school will see all orders with their statuses (design inspired by Shopify). Can view order by dates but custom dates is being worked on. Can leave a customer (parent in this case) note and staff-only-comments. I hope this minimal setup is enough for a school. I'll do the same for the meals but it needs a huge change to allow discounts should a parent has a child/ren that goes to the school and could use discounts for meal and/or for the one-off payments. Any recommendations? At this stage, I'm 100% flexible on changes. BTW the graphs are using fake data for now.

😂 I'm proficient with MySQL and I do get what you are saying. You have the experience in this sector and knows what information is required. I'm here for knowledge and feedback and I'll change it to PostgreSQL. This saves me from issues down the line. To all others, thanks for finding the bugs on the website ie someone messed with the DOM and changed the title to "Rev" (before it's now supported) and some others. Yes, I've seen them 😉

It's early days and things change

Thanks. Im using ruby on rails with a MYSQL DB (all instances on one server: everything). I'll be moving to a tenancy setup but that's way down the line. Not looking to go advance during an evaluation mode.

Hi. It's only me. The plan is to get funding once I have evidence of schools willing to use the platform. If no funding, and the app is profitable, I'll hire people. For the start, it will be only me.

While building this app, best practices will be my #1 priority though I'm not 100% a devOps person 🫣

I really value these questions. Nothing is perfect and apps do go offline at times. I would imagine this would be very critical to any school at that time. It should be worthless if we look it. Any app would be rendered useless unless the school has a Plan B in place where they know who gets what etc. There are two things I could do: Each morning, canteen would know what to prepare and who gets what Implement an offline feature for crucial webpages (difficult) That way schools can operate in the event the website/app is down temporally. I'll add this to my todo.

Solid questions. Though not yet implemented (staff members, canteen login), but when I do, their sensitive data will be redacted from any databases, backups etc when deleted*. When a student leaves and the parent's account has a positive balance, there will be a refund button (not yet implemented) for them to get any money back. No need to email or phone any one (the way we all like it). I will have to implement that but schools will be able to delete anything created from a parent (on my list of things to do). Will get this implemented. * Soft delete that will only remove (redact) sensitive data. Addresses, contact numbers will be deleted.

I know! 😂 Any suggestions? It needs a name in Stripe.

As promised, payments, school global debt limit and per-parent basis debt limit is live on the website. Website is using Stripe test environment so please to use their test card 4000000000000077. Exp date should be in the future ie 11/29 and any last 3 digits: 111 To recap, a school takes payments from a pot. A pot must be created for a school you wish to pre-order from (done already). In the future there will be a how-to section with videos. I guess I now need to focus on the school section UI then find ways for anyone to have their own demo data to play with. I've also posted a video on Twitter/X if you want to see it in action. To delete a pot, the balance must be zero and a school has no activity on it. If you've only just created a pot, the pot has a zero balance, it can be deleted. Any questions, I'm always here.

Schools are now able to set a debt limit which means a parent/carer will not be able to make any current or future orders when that debt limit is reached. This is only possible when I introduced "Pots". The idea was "borrowed" from Monzo Pots. With pots, a pot is assigned to a school and all payments, including future payments, will be deducted from that pot. By introducing pots, I'm now able to set rules around the school's debt limit. Having one account that "feeds" all schools won't be possible. If your account is currently in minus (debt) and another school does not allow debt on the account, it wont be possible for the parent to make a pre-order for the school that disallows debt on the account. You'd have to clear that balance first before doing so. With Pots, you can to-up directly onto a pot where the school does not allow debt on the account, then use that pot at checkout. Everything is one place. All children, from that school, will use that pot. See attachments. Hope to have a live demo by early or mid of next week.

Since we've introduced schools should have control around debt limit, there are now some huge changes to the checkout process. It's no longer possible to have one pot. School "A" allows debt while School "B" does not. Though there will be one pot, monies can be moved around for these schools. If I deposit £10, I could easily transfer money to School B's pot. You can also deposit directly into either School's pot when topping up. Would love to demo this in a a few days time. This way School B will know if the parent/carer has any money for a meal or can keep track of the debit limit. This is getting interesting.

MVP is in the mix. I use the term mvp because where I want Tuicamp to be, I can only make it a cashless app to begin with. I'm the sole developer here so I cannot use the term Agile or any other development methodologies. I make changes based on the feedback received. My focus is to get the this cashless app into the hands of a school for testing/trial later in the year.

All responses are welcomed, Rob_D. At this stage, the app is a simple cashless payment system. I have previous projects where I could pull code from and place into Tuicamp, with a bit of tweaking. By all means it's not rushed. It will take a few more months before I'm at the individual demo stage where the demo data is unique to the logged in account. I totally forgot the school will need to set their own "rules" and that's the next step. By summer, version 1 should be born.

I agree. I'll have this implemented.

I would believe that a child must be fed at school which means there will be a debt on the account if balance is low. I have things in place to prevent this such as you top-up before making a pre-order. The "top-up" account will only be debited once the meal was taken. Worst case is a debt will be recorded and the parent would need to top-up to cover balance. If a child could be refused lunch, then I could implement other features to work with that.

Yes but I'll always be liable for chargebacks, but that should be ok as every seller is liable someway or the other. The top-up is now completed and money transferred to the school works fine, less any fees. Needs polishing before it's available on the website to demo.

Now I see the issues. Yes a child could add more items for the parent to pay later which could lead to issues. I'll implement "credits" but this opens me up for chargebacks etc, which I was running away from but I guess it should be ok. In that case, I'll leave the "top-up" feature and find ways to make this work which means the school will then request payment from me. I guess I'd need some Ts & Cs for this method. Good spot. Thanks.

I finally had a call with a Stripe's representative regarding my payment business model. The initial plan was to have a top-up pot for each parent/carer. This "pot" would "feed" a student, regardless of the school they attend, once they use the platform. Stripe does not support the "top-up" feature because there's no where to store that "virtual money". It will be that a parent/carer would need to have a payment source attached: banking card or/maybe a bank account. For children that are not eligible for free meals, their parent will only be liable for payment after a meal was taken. The platform will then attempt to take payment, say, £3.50 for that meal from that parent/carer attached payment source. At this stage, payment could fail. When failed, we'll send a notification to the account holder (parent) of any events until a payment was successful. Yes, parent will still have full control to stop this reattempts if they deem something is wrong but by doing so will open up a dispute with the school and themselves (parent/carer). Any pre-order will become a debit until actioned. I, myself, as a parent would be ok with this once I still have full control of what goes out of my funding source. To recap, there will not be a top-up feature and actual payment will be made once their child has taken a "paid for" meal. One-off items will require upfront payment.

I'm almost done with the notifications. Notifications will be delivered via email, for now. Hopefully I'll have this live by next week. In a few months I should have have both SSO (MS and Gmail) working with each user with their own demo to play with, privately. At that stage, I'd consider the app to be stable.

Glad you brought that up. There's an audit on the student side for when anything change, and by who, it's recorded. There's no UI for it as yet. Good point for the notification. I'd do just that.

Using Ruby on Rails. I would still need to support all those accounts ie getting a client ID/Secret to use in my application, and I would like not to do so at this stage. Only Gmail and Microsoft I'm considering.

I've looked into the SSO option for parents and it's not possible right now. Remember that the school adds the parent/carer (pc). That pc may have an email address from Apple, Google, Hotmail, any. I wont be going that route to support all those logins. I'll stick with email/password log in, for now. It works perfectly fine with, say, ParentPay. I will be looking into mygovscot and see what's that about. For schools, I could easily add Microsoft. These options would be last on my list.