Budżet: 12345 RUB Termin: 1 dzień
Здравствуйте. Пишу на Swiftе более 2 лет. Могу помочь с вашим приложением. По срокам и бюджету могу точно сказать после ознакомления с дизайном. Спасибо
Ищем iOS Developer для разработки приложения для частного авиаперевозчика:
• Опыт коммерческой разработки iOS-приложений не менее 1 года.
• Владение Swift и Objective-C на высоком уровне.
• Уверенные знание в iOS и его базовых фреймворков.
• Знание особенностей системы iOS и жизненного цикла приложений.
• Опыт работы с RESTful сервисами для клиент-серверных приложений.
• Знание инструментария для отладки, оптимизации (Instruments и т.п.) и распространения (TestFlight и т.п.).
• Знание UI/UX стандартов для iOS (Mobile HIG и т.п.).
• Английский язык
Рейт $15-20, обсуждается
Budżet: 12345 RUB Termin: 1 dzień
Здравствуйте. Пишу на Swiftе более 2 лет. Могу помочь с вашим приложением. По срокам и бюджету могу точно сказать после ознакомления с дизайном. Спасибо
Budżet: 120000 RUB Termin: 23 dni
давайте посмотрим на детали и оценим адекватно ваш проект. обращайтесь.
Budżet: 7777 RUB Termin: 77 dni
Здравствуйте
Могу предложить на swift или flutter
Дизайн уже готов?
Budżet: 11111 RUB Termin: 111 dni
Добрый день.
Готов выполнить ваш проект.
Мой опыт разработки под IOS на Swift более 3 лет.
English: Upper intermediate I think.
Ставка: 15$/час.
Резюме скину в личные сообщения.
Budżet: 11111 RUB Termin: 30 dni
Здравствуйте. Опыт iOS разработки 10 лет, делаю качественно. Рейт от 20$/час, для начала хотелось бы ознакомиться с ТЗ и дизайном, для оценки времени.
Opracowanie aplikacji Power App, wsparcie mnie jako nowicjusza. Canvas App, pomoc w opracowaniu ekranu Pomoc w opracowaniu struktury danych dla aplikacji Programowanie funkcji Pomoc w tworzeniu tabel Date-verse
Potrzebna pomoc w przemyśleniu i zbudowaniu czystiej schemy relacyjnej dla wewnętrznego systemu operacyjnego w Airtable. Obecna baza jest już używana przez zespół, ale rozwinęła się organicznie: struktura jest częściowo płaska, część tabel/widoków jest używana aktywnie, część prawie nie jest używana, a dokumenty teraz raczej "ciągną" informacje do Airtable, chociaż w idealnym przypadku Airtable powinno stać się źródłem prawdy i generować potrzebne artefakty operacyjne. Potrzebna jest nie tylko pomoc w formularzach czy automatyzacjach, ale przede wszystkim praca strukturalna: analiza obecnej logiki, projektowanie schemy relacyjnej, stworzenie czystej nowej bazy/instancji, dokumentacja oraz rekomendacje dotyczące migracji do nowej schemy. I potencjalnie możliwe nawet wdrożenie Kontekst systemu: Są dwa główne kierunki: System feedbackowy System do zbierania i przetwarzania sygnałów od zewnętrznych doradców, grup fokusowych, wewnętrznych zespołów oraz interesariuszy. Musi wspierać: rejestr sygnałów; śledzenie doradców; przyjmowanie feedbacku; panel syntezujący; statusy / bramki / rekomendacje; logikę zamykania pętli. Katalog produktów W katalogu produktów jest obecnie około 400 wpisów, z czego około 100 jest aktywnych/na żywo. Należy lepiej zorganizować produkty, statusy, powiązania, źródła danych, logikę cyklu życia/bramki oraz raportowanie. Obecny stan: Airtable już istnieje i jest używane przez zespół. Obecna dokładność danych wynosi około 80%. Schemat jest głównie płaski, nie relacyjny. Aktywnie używane są tylko pierwsze kilka tabel/zakładek: Część bramek walidacyjnych, zadań/decyzji i widoków panelu jest na razie prawie nieużywana. Nie ma PII. Jakakolwiek praca z bazą na żywo musi być maksymalnie ostrożna: bez zmian w produkcji bez zgody. Idealne podejście to analiza struktury i budowa nowej czystej bazy osobno w Sandboxie. Co należy zrobić: Faza 1 — Audyt i rekomendacja architektury Przyjrzeć się obecnej strukturze Airtable. Określić, które tabele/pola/widoki są naprawdę potrzebne, które się powtarzają, które można połączyć lub usunąć. Proponować model danych relacyjnych. Opisać główne encje, relacje, klucze główne, powiązane rekordy, logikę wyszukiwania/rolowania. Proponować czystą schemę dla Projektu + Katalogu produktów. Określić, jakie panele/interfejsy są potrzebne dla różnych użytkowników. Przygotować krótką notatkę architektoniczną lub mapę schemy. Faza 2 — Budowa czystej bazy Airtable Stworzyć nową czystą bazę Airtable / instancję. Skonfigurować tabele, pola, powiązane rekordy, widoki, podstawowe interfejsy. Skonfigurować podstawową logikę panelu/raportowania. Przygotować mapę migracji: jak przenosić dane ze starej struktury do nowej. Udokumentować strukturę tak, aby zespół mógł ją wspierać po przekazaniu. W razie potrzeby — zaproponować strategię automatyzacji, ale bez nadmiernej złożoności. Oczekiwane rezultaty: Mapa schemy Airtable. Nowa czysta baza Airtable. Tabele + relacje + kluczowe pola. Widoki/interfejsy dla głównych użytkowników. Rekomendacja migracji. Krótką dokumentację dla zespołu. Rekomendacje dotyczące zarządzania: kto wprowadza dane, kto zatwierdza zmiany, które pola są obowiązkowe, jak unikać duplikacji. Opcjonalnie: 1 krótka rozmowa przekazująca / przejście przez Loom. Ważne zasady dotyczące bezpieczeństwa / dostępu: Bez PII. Bez niebezpiecznych tokenów lub osobistych integracji. Nie można podłączać AI/MCP/ChatGPT/Claude do bazy Airtable na żywo. Jeśli potrzebny jest dostęp do istniejącej bazy, musi być tylko do odczytu lub przez eksport/zrzuty ekranu/opis strukturalny. Jakiekolwiek zapisy/zmiany są dokonywane tylko w nowej testowej/czystej bazie, nie w produkcji na żywo. Kogo szukam: Idealny kandydat ma doświadczenie: w architekturze bazy Airtable; w projektowaniu schem relacyjnych; w interfejsach Airtable, widokach, formularzach, automatyzacjach; w migracji/oczyszczaniu chaotycznych baz Airtable; w operacjach produktowych / CRM / systemach workflow; w dokumentacji i przekazywaniu. W odpowiedzi proszę podać: Przykłady baz Airtable lub systemów, które budowałeś. Czy miałeś doświadczenie w przekształcaniu płaskiej struktury Airtable w schemę relacyjną. Jak podszedłbyś do audytu → projektowania schemy → budowy. Orientacyjną ocenę godzin dla Fazy 1. Twoją stawkę godzinową lub ofertę stałą na pierwszy etap. Czy jesteś gotów pracować na podstawie NDA. Format pracy: Rozpoczęcie najlepiej w najbliższym czasie. Na początku można przeprowadzić niewielkie płatne odkrycie/audyt, po czym przejść do pełnej budowy.